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FOREWORD 

• 

• 

This  technical  report  covers  work  performed  under  Air  Force 

Contract  F3 3600-87-C-0464 ,  DAPro  Project.  This  contract  is 
sponsored  by  the  Manufacturing  Technology  Directorate,  Air  Force 

Systems  Command,  Wright-Patterson  Air  Force  Base,  Ohio.  It  was 
administered  under  the  technical  direction  of  Mr.  Bruce  A. 

Rasmussen,  Branch  Chief,  Integration  Technology  Division, 

Manufacturing  Technology  Directorate,  through  Mr.  David  L. 

Judson,  Project  Manager.  The  Prime  Contractor  was  Integration 

Technology  Services,  Software  Programs  Division,  of  the  Control 

Data  Corporation,  Dayton,  Ohio,  under  the  direction  of  Mr.  W.  A. 

Osborne.  The  DAPro  Project  Manager  for  Control  Data  Corporation 
was  Mr.  J.  P.  Maxwell. 

The  DAPro  project  was  created  to  continue  the  development,  test, 
and  demonstration  of  the  Integrated  Information  Support  System 
(IISS).  The  IISS  technology  work  comprises  enhancements  to  IISS 
software  and  the  establishment  and  operation  of  IISS  test  bed 
hardware  and  communications  for  developers  and  users. 

The  following  list  names 
subcontractors  and  their 

the  Control  Data  Corporation 
contributing  activities: 

SUBCONTRACTOR 

ROLE 

Control  Data  Corporation 

Responsible  for  the  overall 

Common  Data  Model  design 
development  and  implementation, 

IISS  integration  and  test,  and 
technology  transfer  of  IISS. 

D,  Appleton  Company 

Responsible  for  providing 
software  information  services  for 
the  Common  Data  Model  and  IDEFIX 
integration  methodology. 

ONTEK 

Responsible  for  defining  and 
testing  a  representative 
integrated  system  base  in 

Artificial  Intelligence 
techniques  to  establish  fitness 
for  use. 

Simpact  Corporation 

Responsible  for  Communication 
development . 

- 

Structural  Dynamics 
Research  Corporation 

Responsible  for  User  Interfaces, 

Virtual  Terminal  Interface,  and 

Network  Transaction  Manager 
design,  development, 
implementation,  and  support. 

Arizona  State  University 

Responsible  for  test  bed 
operations  and  support. 
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1 . 1 


Overview 


SECTION  1 


GENERAL 


The  Electronic  Documentation  System  provides  an  integrated 
set  of  tools  that  enable  the  user  to  create,  edit,  revise,  and 
generate  documents  with  a  well-defined  logical  structure  and  a 
well-defined  layout  structure.'- 


The  EDS  operates  in  the  IISS  environment  on  those  host 
systems  which  support  IISS.  EDS  was  designed  and  developed  to 
accept  input  from  and  produce  output  for  those  devices  which  are 
supported  within  the  IISS.'-- 


The  EDS  is  a  document  authoring  system  that  can  be  used  to 
combine  both  text  and  graphics  into  a  single  document.  In 
addition,  EDS  separates  the  content  development  from  document 
structure  and  format.  The  EDS  interfaces  with  the  IISS  via  the 
User  Interface  Form  Processor. 


All  EDS  application  programs  which  require  user  input  use 
the  Form  Processor.  The  Form  Processor  ensures  that  all  EDS 
application  programs  present  a  common  forms-based  user  interface 
for  the  necessary  user-entered  input. 

1 . 2  Purpose 

The  problem  confronting  many  an  author  is  compelling. 
Authors  must  somehow  ensure  that  all  the  various  requirements 
for  a  document  are  met  correctly  in  the  time  allowed.  The  EDS 
v;as  developed  to  assist  the  author  is  this  effort. 

EDS  allows  for  the  separation  of  the  author  from  the  format 
or  layout  requirements  of  a  document.  The  author  is  separated 
from  the  document  structure  considerations.  Presently,  many 
technical  documents  are  developed  by  an  author  who  must  be 
concerned  with  content,  format,  and  structure. 
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These  are  the  steps  in  the  creation  of  a  document  using 

EDS  : 

1.  Define  the  document  type. 

2.  Define  logical  structure  of  the  document  typ a . 

3.  Define  the  document  layout  style. 

4 .  Develop  the  document  content 

A.  Markup  or  tag  the  document  content  in  English-like 
commands,  i.e.  SGML 

B.  Author  can  include  any  special  requirements  as 
defined  in  the  layout  style. 

C.  Document  produced  in  VAX  WPS  can  be  run  through  the 
EDS  Tagger  to  strip  out  WPS  control  characters  and 
replace  with  document  type  information. 

5.  Completed  document  content  is  parsed 

A.  This  would  include  the  WPS  document  which  has  been 
run  through  the  Tagger. 

6.  Document  is  ready  for  the  Formatter 

A.  External  graphics  files  are  run  through  the 
appropriate  conversion  program  for  inclusion  into 
the  final  form  document. 

B.  The  parsed  document  content,  the  output  of  Step  5 
is  ready  for  the  Formatter. 

C.  The  graphics  and  the  parsed  document  are  combined 
in  this  step  for  the  final  output  form  of  the 
document . 

The  above  outlined  steps  are  the  overall  steps  in  the 
development  of  an  EDS  document.  Not  all  document  developers, 
especially  authors  of  document  content,  are  required  to  follov; 
these  steps.  The  EDS  was  produced  to  separate  these  steps  or 
functions  for  document  developers.  The  author  of  a  document 
would  be  independent  of  many  of  the  above  steps. 
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Attribute ;  A  characteristic  used  to  qualify  an  element 

within  a  document. 

Character  Set:  A  mapping  of  a  character  repertoire  onto  a 

code  set  such  that  each  character  is  associated  with  its  coded 
representation . 

Compound  Document:  A  document  which  may  contain  mixed  content 

i.e.  text,  graphics,  etc. 

Conforming  SGML  Application:  An  SGML  application  that 

requires  documents  to  conform  to  SGML  documents,  and  whose 
documentation  meets  the  requirements  of  this  International 
Standard . 

Conforming  SGML  Document:  An  SGML  document  that  complies  with 

all  provisions  of  ISO  8879. 

Cursor  Position;  The  position  of  the  cursor  after  any  command 
is~Tssued  or  in  a  certain  location  on  the  computer  screen 
display. 

Descriptive  Markup;  Information  added  to  a  document  which 
enables  an  application  program  to  process  the  document. 

Element ;  A  component  of  the  hierarchical  structure  defined  by 
a  document  type  definition;  it  is  identified  in  a  document 
instance  by  descriptive  markup,  usually  a  start-tag  and  end-tag. 

Ent i ty :  A  collection  of  characters  that  can  be  referenced  as 

a  unit. 

Field;  A  two-dimensional  space  on  a  terminal  screen. 

Form ;  A  structured  view,  presented  on  a  computer  screen 
display,  which  may  be  imposed  on  windows  or  other  forms.  A  form 
is  composed  of  fields,  these  fields  may  be  defined  as  forms, 
items,  or  windows. 

I ISS :  Integrated  Information  Support  System  ,  a  test 

computing  envirionment  used  to  investigate,  demonstrate,  and 
test  the  concepts  of  information  management  and  information 
integration  in  the  context  of  Aerospace  Manufacturing.  The  I ISS 
addresses  the  problems  of 
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integration  of  data  resident  of  heterogeneous  data  bases 
supported  by  heterogeneous  computers  interconnected  via  a  Local 
Area  Network. 

IISS  Function  Screen:  The  first  screeen  that  is  displayed 

after  logon.  It  allows  the  user  to  specify  the  function  to 
access  and  the  device  type  and  device  name  on  which  to  work. 

Menu :  A  screen  display  which  presents  user  selectable 

functions  or  actions  to  be  taken. 

Message :  Descriptive  text  which  may  be  returned  in  the 

message  line  on  the  terminal  screen.  Messages  are  used  to  warn 
of  errors  or  provide  additional  information. 

Message  Line:  A  line  on  the  terminal  screen  that  is  used  to 

display  messages. 

PDA;  Office  Document  Architecture,  a  standard  which  supports 
the  interchange  of  electronic  compound  documents  in  such  a  v.-ay 
as  to  allow  their  imaging,  processing,  or  reformatting. 

PDIF;  Office  Document  Interchange  Format,  a  standard  for 
encoding  document  structures  defined  by  the  PDA  which 
would  enable  the  exchange  of  compound  documents  between  systems 
operating  within  a  MAP/TOP  environment. 

SGML;  Standard  Generalized  Markup  Language,  a  language  for 
describing  document  structures,  consisting  of  descriptive  markup 
which  is  added  to  a  document  to  indicate  where  logical  elements 
such  as  sections  and  paragraphs  begin  and  end. 

Tag :  Descriptive  markup  indicating  the  start  or  end  of  a 

logical  element. 

Window ;  Dynamic  area  of  a  terminal  screen  on  which 

predefined  forms  may  be  placed  at  run  time. 
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SECTION  3 
THE  EDS 


3 . 1  Purpose  of  System 

The  EDS  is  a  system  for  document  processing.  Document 
processing  is  accomplished  by  various  methods.  These  methods 
include  typesetting,  typewriters,  word  processing  systems, 
desktop  publishing  systems,  and  other  specialized  packages. 

Text  processing  has  been  recognized  as  an  important  phase  in  the 
development  and  the  delivery  of  any  product. 

The  selected  text  processing  standard  for  the  EDS 
is  the  Standard  Generalized  Markup  Language  (SGML) .  SGML  is  an 
International  Standards  Organization  (ISO)  standard.  This 
standard  is  a  descriptive  high  level  language  which 
structures  and  formats  text.  The  formatting  of  text  is  that  set 
of  commands  that  physically  presents  the  text  on  the  printed 
page . 

There  are  other  languages  that  format  and  structure 
documents.  These  are  usually  procedural  markup  languages. 
Procedural  markup  languages  embed  the  format  and  structure 
requirements  in  the  document  text.  This  can  be  seen  in  most 
word  processing  systems. 

Physical  presentation  of  the  text  includes  the  structure 
of  the  text  and  the  format  of  the  text.  There  are  special 
processing  techniques  for  the  structure  of  the  text.  These 
structural  requirements,  for  example,  may  include: 

the  commands  for  a  section  title 
a  paragraph  heading 
a  list 

a  figure  or  illustration 
a  glossary 
an  appendix 
an  index 

The  format  of  the  text  includes  special  requirements  also. 
Format  requirements  may  include; 

the  page  number  location 

the  use  of  a  top  notation  on  the  page  (a  header) 
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the  use  of  a  bottom  notation  on  the  page  (a  footer) 

the  margin  setting  for  the  text 

the  numbers  of  lines  to  a  page 

the  size  (pitch)  of  the  characters 

the  style  (font)  of  the  characters 


3 . 2  Logical  Structure  in  Documents 

A  book  is  a  compilation  of  information  on  a  subject, 
whether  that  subject  be  fiction  or  fact.  A  book  that  is 
purchased  from  a  bookstore  has  a  defined  structure  to  it.  This 
structure  can  be  defined  as:  a  front  cover,  a  copyright  and 
trademark  page,  a  title  page,  a  table  of  contents,  subsequent 
chapters,  subsequent  paragraphs  in  those  chapters,  an  index,  and 
a  back  cover.  There  is  implied  in  this  structure  a  certain 
generic  sequence.  The  front  cover  to  the  table  of  contents  can 
be  considered  the  "front  matter"  of  the  book.  The  chapters  and 
paragraphs  can  be  considered  the  "body".  The  index  and  back 
cover  can  be  considered  "back  matter". 

The  technical  document  structure  can  be  expressed 
similarly,  for  example,  an  ICAM  document  type.  Let's  define  the 
structure  of  a  unit  test  plan:  the  title  page,  the  notice  page, 
the  government  distribution  page,  the  preface,  the  table  of 
contents,  the  list  of  illustrations,  the  major  sections, 
paragraph  headings  with  numbers,  paragraphs,  appendices  (as 
required) ,  an  index,  and  perhaps  a  glossary.  The  title  page  to 
the  list  of  illustrations  would  be  the  front  matter.  The 
sections  to  the  appendices  would  be  the  body.  The  index  and  the 
glossary  would  be  the  back  matter. 

As  you  can  see  from  the  two  structures  that  we  have  defined 
there  is  a  starting  point  (the  front  matter) ,  a  middle  (  the 
body) ,  and  an  ending  point  (the  back  matter)  for  the  book  and 
the  technical  document.  This  can  be  termed  logical  structure. 

A  document  structure  must  be  clearly  understood  when  defining  a 
document  type  in  the  EDS. 

3.2.1  Document  Types 


Now  that  we  have  been  able  to  understand  a  high  level 
document  structure,  we  must  begin  to  understand  the  lower  levels 
of  the  document  structure.  We  are  going  to  analyze  the 
additional  elements  of  the  logical  structure  of  a  document. 

Logical  document  structure  can  be  expressed  as  an  hierarchy 
of  parents,  children,  and  groups  of  parents  and  children.  The 
document  structure  is  composed  of  a  high  level  or  generic 
component  that  has  lower  level  elements.  These  lower  level 
elements  may  be  composed  of  other  lower  level  elements  also. 

This  is  how  the  terms  parent  (high  level  element)  and  child  (low 
level  element)  have  evolved.  Without  the  parent  there  would  be 
no  child,  a  child  may  be  a  parent  to  another  child,  and  so  on. 

A  parent  or  a  child  may  have  siblings  also.  A  sibling  to  front 
matter,  for  example,  would  be  body. 
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As  an  EDSDTD  user,  you  will  define  the  hierarchy  of  a 
document  in  the  expression  of  the  relationships  between  the 
parents  and  children  within  a  document.  These  logical  elements 
will  also  be  described  to  the  system  by  the  number  of 
occurrences  for  each  element. 

In  addition  to  the  hierarchical  structure  of  the  document 
type,  there  may  be  descriptors  to  the  elements  of  the  structure. 
These  descriptors  are  called  attributes.  An  attribute  could 
further  qualify  an  element.  As  an  example,  the  logical 
structure  element  book  may  have  a  status  attribute  associated 
with  it  which  defines  the  book  to  be  a  draft  or  final  copy. 
Element  and  attribute  statements  are  the  basis  of  the  definition 
of  a  document  type  logical  structure. 


3.2.2  Document  Hierarchy  and  Logical  Structure 

The  creation  of  a  document  involves  analyzing  the  document 
type  to  be  created.  Document  analysis  is  accomplished,  by  many 
authors,  by  the  use  of  an  outline  of  the  basic  structure  of  the 
document.  This  outline  can  be  used  to  illustrate  the  hierarchy 
of  the  logical  structure  of  the  document.  Let's  analyze  and 
outline  an  unit  test  plan  as  our  test  example. 

The  unit  test  plan  would  follow  those  general  requirements 
as  documented  in  the  ICAM  Documentation  Standard.  The  generic 
logical  structure  of  this  unit  test  plan  would  be  front  matter, 
body,  and  rear  matter.  Let's  briefly  outline  this  document: 

unit  test  plan 

Front  Matter 

Cover  Page 
Notice  Page 

Government  Distribution  Page 
Preface 

Table  of  Contents 
List  of  Illustrations 
List  of  Tables 
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Body 

Section  One 
Section  Two 
Section  Three 
Section  Four 
Appendix  A 

Rear  Matter 
Index 
Glossary 


The 
elements 
example , 


outline  could  be  further  developed  to  include  those 
of  each  of  these  level  elements  that  we  listed.  For 
Cover  Page  could  be  further  described: 


Cover  Page 

Title  of  Project 

Title  of  Configuration  Item 

Title  of  Computer  Program 

Date 

Address  of  Developer 
Addres  line  1 
Address  line  2 
Address  line  3 
Address  line  4 


As  you  can  see  from  this  further  breakdown  of  the  element  Cover 
Page,  there  are  many  other  elements  that  could  be  defined. 

3 . 3  EDS  Components 

EDS  is  composed  of  tools  that  enable  a  user  or  group 
of  users  to  create,  edit,  revise,  and  generate  documents. 

These  documents  may  span  all  types  of  generated  text  from  a 
simple  office  memo  to  a  complex  specification.  Most 
importantly,  EDS  will  support  the  compound  document 
which  combines  text  and  graphics  together. 

The  various  components  of  EDS  support  certain  functions  of 
the  system.  Those  functions  include  the  definition  of  a 
document  type,  the  layout  or  format  definition,  the  conformance 
to  the  document  type,  the  conversion  from  the  WPS  word 
processing  package  to  SGML,  the  inclusion  of  graphics  from 
external  sources,  and  the  formatting  of  the  document  for  print. 
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The  following  lists  the  functions  and  each  component  for  the 
function . 

1.  The  definition  of  document  type  is  found  in  the  DTDBLD. 

2.  The  layout  or  format  definition  is  found  in  the  Layout 
Editor. 

3.  The  conformance  to  document  type  is  found  in  the  SGML  Parser. 

4.  The  conversion  from  word  processing  package  is  found  in  the 
Tagger. 

5.  External  graphics  conversion  and  inclusion  into  document  is 
found  in  the  Graphics  section. 

6.  Formatting  the  document  for  print  is  found  in  the 
Formatter. 

3.4  EDS  User  Manual  Structure 


This  unit  test  plan  is  structured  to  give  the  general 
user  the  information  necessary  to  function  properly  in  EDS. 

There  are  several  steps  that  must  be  followed  to  ensure  that 
the  system  will  give  optimum  performance  to  the  user.  The 
structure  of  this  manual  assists  in  familiarizing  the  user 
with  the  concepts  of  logical  structure,  layout  structure, 
generic  ids  or  macros,  and  other  text  processing  terminology. 

The  following  sections  discuss  the  individual 
components  of  EDS.  Each  component  has  specific  examples 
of  text  processing  concepts  as  necessary.  The  Formatter,  for 
example,  requires  some  information  from  the  user.  However,  this 
is  specific  information  with  no  real  text  processing 
concepts  to  understand. 


Remaining  sections  of  this  manual  are  organized  as  follov.s; 


Section  4 
Section  5 
Section  6 
Section  7 
Section  8 
Section  9 


DTDBLD,  build  of  document  types 
Layout  Editor,  definition  of  layout 
SGML  Parser,  parsing  document  for  SGML 
Tagger,  conversion  of  word  processing  file 
Graphics  in  the  EDS 

the  Formatter,  production  of  final  form 
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Each  area  of  discussion  includes  component  error  messages, 
functions,  help  tools,  and  key  sequences  to  be  typed  in. 

As  we  progress  through  these  areas  a  sample 
document  is  used  to  illustrate  the  logical  structure,  the  layout 
structure,  and  the  graphics  for  the  document.  An  example  of 
document  source  text  can  be  found  in  Appendix  B. 

3 . 5  Accessing  the  EDS 

There  are  two  methods  of  accessing  the  EDS.  EDS  was 
developed  as  an  IISS  tool  and  is  therefore  accessed  from  the 
IISS  Function  Screen.  The  EDS,  including  all  the  components 
that  comprise  the  system,  may  be  accessed  through  the  IISS. 
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SECTION  4 

DOCUMENT  TYPE  DEFINITION  BUILDER  (DTDBLD) 


This  section  is  intended  to  give  the  user  the  information 
necessary  to  begin  building  documents  in  the  EDS.  An 
understanding  of  document  types  and  how  to  define  them  is  of 
utmost  importance  for  the  user  of  EDS.  Additionally,  the 
ability  to  understand  the  logical  structure  of  a  document  is  a 
prerequisite  to  the  DTDBLD  function.  These  concepts  are 
discussed  in  Section  3.2  and  3.4  respectively. 

4.1  DTDBLD 

This  is  the  program  module  of  the  EDS  that  defines  the 
document  type  and  the  document  structure.  The  logical  structure 
of  the  document  will  be  defined  in  the  DTDBLD  program.  This 
program  can  be  accessed  by  logging  into  the  IISS,  entering 
EDSDTD  at  the  "Function"  input  prompt,  and  pressing  the  <ENTER> 
key. 

After  the  previous  screen.  Figure  3-2,  the  EDS  Document 
Type  Definition  Builder  screen  will  appear.  A  list  of  existing 
document  type  definitions  will  appear  in  the  form.  This  list  is 
scrollable  and  can  be  scrolled  using  the  <SCROLL/PAGE>  mode  key 
defined  in  the  IISS  Terminal  Operator  Guide. 


Figure  4-1  EDS  Document  Type  Definition  Builder  Screen 
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There  are  only  four  actions  that  can  be  performed  on  a  DTD. 
These  actions  are; 

1.  E  (dit) 

2.  C  (opy) 

3.  D  (elete) 

4.  S  (earch) 

These  actions  can  be  entered  into  the  form  in  two  different 
ways.  The  action  can  be  entered  directly  on  the  first  input 
line  of  the  form  along  with  the  DTD  name.  Completion  of  the 
action  will  occur  after  the  <ENTER>  key  is  pressed. 


EDS  -  OocuMKt  Typ*  Definition  Builder  1/22/S8  13:S0;S1 


DTD  Naoe  |u«  ~|  [^Action  (E,  D,  C,  S) 

Exiitlng  DTD  Directory  Entries 
Action  DTD  Naee  Description 

~]  osmooc 

ICAHVIT 

ICAMDOC 

Bosvrr 

BDSDID 

DTDBLO 


I  use :  I  0 1 _ epplcetionl 

Figure  4-2  Input  Line  Command  of  DTD  and  action 


The  second  method  for  entering  the  DTD  action  is  through 
cursor  movement.  The  cursor  is  moved  via  the  <TAB>  key  to  the 
desired  DTD  and  the  command  is  entered  in  the  action  field  on 
the  form.  This  action  is  then  processed  by  pressing  the  <ENTER> 
key. 
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EDS  -  Document  D«f  ini  lion  Builder  1/22/88  13756757 


DTD  Htmt  fu»  |  [TjActlon  (£,  D,  C,  S) 

Existing  DTD  Directory  Entries 
Action  DTD  N«m  Description 

“1  DBMOOOC 

icAmrrp 

ICAKDOC 

losurr 

IDSDTD 

DTDBLD 


_ _ _  .pple.tion 


Figure  4-3  Action  for  DTD  in  Tab  Field 

The  creation  of  a  new  DTD  is  accomplished  by  entering  the 
DTD  name,  the  E  (dit)  action  command,  and  pressing  <ENTER>.  The 
modification  to  an  existing  DTD  would  be  accomplished  by  using 
the  E  (dit)  action  in  the  selected  DTD  action  field  and  pressing 
<ENTER>.  The  C  (opy)  command  is  entered  in  this  same  fashion. 

4 . 2  Creating  a  DTD 

The  creation  of  a  DTD  involves  analyzing  the  document  type 
to  be  defined.  This  can  be  done  by  thinking  of  the  document 
that  you  wish  to  create  in  outline  form.  The  outline  can  be 
used  to  illustrate  the  hierarchy  of  the  logical  structure  of  the 
document.  Let's  analyze  and  outline  an  unit  test  plan  as  our 
test  example. 

The  unit  test  plan  would  follow  those  general  requirements 
as  documented  in  the  ICAM  Documentation  Standard.  The  document 
that  we  outlined  in  Section  3.4.1  gives  us  the  hierarchical  or 
logical  structure  of  a  document  to  create  in  the  DTD.  Let's 
review  the  structure  we  outlined  in  the  previous  section.  This 
outline  included  the  generic  type  of  document,  a  unit  test  plan; 
a  generic  beginning  for  the  document,  front  matter;  a 
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generic  content  area  for  the  document  subject  matter,  a  body ; 
and  an  area  for  additional  reference  material  on  the  document,  a 
rear  or  back  matter. 


unit  test  plan 

Front  Matter 

Cover  Page 
Notice  Page 

Government  Distribution  Page 
Preface 

Table  of  Contents 
List  of  Illustrations 
List  of  Tables 

Body 

Section  One 
Section  Two 
Section  Three 
Section  Four 
Appendix  A 

Rear  Matter 
Index 
Glossary 

This  outline  illustrates  the  document  type  level  0,  unit 
test  plan;  the  generic  level  1,  i.e.  front  matter;  and  the  next 
level  2,  i.e  Cover  Page,  for  the  document  structure.  The 
outline  could  be  further  developed  to  include  those  elements  of 
each  of  these  level  elements  that  we  listed.  For  example,  Cover 
Page  could  be  further  described: 

Cover  Page 

Title  of  Project 

Title  of  Configuration  Item 

Title  of  Computer  Program 

Date 

Address  of  Developer 
Address  line  1 
Address  line  2 
Address  line  3 
Address  line  4 

As  you  can  see  from  this  further  breakdown  of  the  element  Cover 
Page,  there  are  many  other  elements  that  could  be  defined. 

We  took  the  level  2  element  Cover  Page  and  defined  the  next 
level  down  from  it.  This  level  3  element.  Address  of  Developer, 
had  children  defined  for  it.  These  children  of  level  3  element 
Address  of  Developer  became  level  4  elements. 

DTDBLD  will  assist  the  user  in  defining  this  hierarchical 
structure  to  each  document  type  defined.  The  user  must 
understand  the  parent-child  relationship  when  defining  this 
structure.  The  DTDBLD  is  considered  a  tool  for  those 
knowledgable  in  document  design,  structure,  and  analysis.  This 
is  especially  true  in  the  creation  of  a  document  type 
def inition. 
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The  required  input  for  you,  the  user,  to  create  a  new 
document  type  definition  and  to  define  that  logical  structure  is 
the  E  (dit)  action  code  on  the  DTDBLD  main  menu  or  screen 
display.  To  create  the  document  type,  unit  test  plan,  the 
required  inputs  would  be  an  E  in  the  action  code  field,  the  name 
of  the  document  type  in  the  DTDname  field,  and  the  pressing  of 
the  <ENTER>  key.  Figure  4-6  illustrates  the  inputs  for  this 
step. 


tOS  •  Oftcuatnt  OtflnTtten  Bulld«r 


OTD  H4M  fu* 


QActton  (t.  D,  C.  S) 


OTT)  Directory  Entries 

Aciloft  OTO  He**  Description 


ICANVrV 

lOIBOC 

Bsvrr 

■DSOTD 

OTMLO 


»pplce« ion 


Figure  4-4  Creation  of  Unit  Test  Plan  DTD  in  DTDBLD  Main  Menu 

The  EDS  will  go  to  the  next  screen  form  for  the  definition 
of  the  document  type.  This  screen  will  resemble  the  following 
f igure . 


UM  620344900 
30  September  1990 


Docuacnt  Hierarchy 


1/22/88  13;5«:49 


Coaaon  Generic  Total  Order  of  Croup  Instance 

Uvel  Naae  Identifier  Instances  Children  aay  Occur  may  occui 

□  I  II  n  □  D  □ 

0 


SEO 


MSG; I  1 |Enter/coaplete  definition  for  root  leeel  eleaent 


applcat ion 


Figure  4-5  Document  Hierarchy  Screen 
4.2.1  Document  Hierarchy 

The  only  input  a''e  ’  on  the  Document  Hierarchy  Screen  is 
that  for  the  DTD  it'o‘...lf  (remember  level  0  from  our  outline).  It 
is  up  to  the  r.sc:  to  now  describe  and  define  the  rest  of  the 
docum;  nr.  logical  structure-  Again,  our  outline  should  come  in 
handy  for  this  definition. 

The  level  1  elements  should  be  entered  into  the  form. 

Those  elements  (again  from  our  outline)  would  be  front  matter, 
body,  and  rear  matter.  The  form  input  areas  to  be  filled  in 
include  the  level,  the  common  name,  the  generic  identifier,  the 
total  instances  of  the  element,  the  order  of  children,  how  often 
the  group  may  occur,  and  how  often  the  instance  of  the  group  may 
occur.  These  input  fields  have  significant  impact  to  the 
document  structure.  The  input  fields  and  meanings  follow. 

Level :  The  number  of  the  element  in  the  document 

hierarchy,  beginning  the  document  type  at 
level  0. 
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The  name  associated  with  the  element,  not 
one  that  is  an  abbreviation  or  a  devised 
term  for  the  element. 

This  would  be  a  term  devised  for  the  element 
or  an  abbreviation. 

This  is  system  generated. 

This  is  a  necessary  input  that  will  tell  the 
EDS  how  to  process  the  children  of  a  given 
element . 

The  system  accepts  only  the  following  for  this  input  field: 

SEQ:  All  elements  will  occur  in  required  order,  i.e. 

sequential  order 

NSEQ:  All  elements  will  occur,  but  in  no  special  or  required 

order,  i.e.  non-sequential  order 

OR:  One  and  only  one  of  the  children  will  be  used 

NONE:  There  are  no  children  to  this  parent 

Group  May  Occur:  Defines  how  often  an  element  may 

(Children)  occur,  possible  values  are: 

Zl:  Zero  or  one  time 

ZM:  Zero  or  many  times 

IM:  One  or  many  times 

1 :  Once 


Instance  May  Occur:  Defines  how  often  that  instance  of  the 

element  may  occur,  possible  values  are  the 
same  as  that  of  above  Group  (Zl,  ZM,  IM,  1) 

The  actions  performed  in  the  Document  Hierarchy  Form  are 
Search  and  List  document  type  elements.  Insert  elements,  and 
Delete  elements. 


Common  Name: 

Generic  Identifier: 

Total  Instances: 
Order  of  Children: 
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4. 2. 1.1  Search  and  List 

This  is  the  default  action  of  the  Document  Hierarchy  Form. 
When  this  form  is  accessed  from  the  DTDBLD  Main  Menu,  it 
automatically  does  a  search  for  the  elements  and  a  list  of  the 
elements  that  compose  the  document  type.  For  a  newly  created 
document  type  there  will  be  no  elements  except  that  of  the 
document  type  itself,  level  0. 


Figure  4-6  Document  Hierarchy  Form 
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4. 2. 1.2  Display  Document  Hierarchy 

The  elements  that  you  have  entered  into  the  Document 
Hierarchy  form  have  defined  the  document  type  and  logical 
structure  to  EDS.  The  ability  to  view  this  logical  structure  at 
the  element  level  is  one  that  will  be  used  for  analysis  of  the 
document.  This  will  be  especially  true  for  verification  of  the 
document  logic  after  initial  definition  of  the  document 
structure . 

There  are  several  functions  that  exist  in  this  form  for  the 
verification  process.  These  functions  are  to  list  the  children 
or  subordinates  of  an  element,  to  display  the  parent  of  the 
element  with  the  parent’s  subordinates,  and  to  assign  attributes 
to  an  element.  A  description  of  these  functions  follows, 
however,  examples  of  the  functions  and  commands  can  be  found  in 
Section  4.4.2  Edit  a  DTD. 

4 . 2 . 1 . 2 . 1  List  Children  of  Element 

This  action  within  the  Display  Document  Hierarchy  Menu  is 
the  default  action  of  the  form.  The  action  taken  in  the 
previous  form,  see  Figure  4-10,  automatically  accesses  this  form 
with  the  element  and  the  list  of  children  for  that  element. 

4. 2. 1.2. 2  List  Parent  of  Element 

This  action  within  the  Display  Document  Hierarchy  Menu  is 
used  to  list  the  parent  of  the  element.  This  screen  list  will 
display  the  element's  parent  and  the  subordinates  of  the  parent. 

Included  in  the  subordinates  displayed  on  the  screen  should  be 

the  element. 

This  action  is  accomplished  by  placing  the  cursor  on  the 
input  line  at  the  top  of  the  form.  The  cursor  should  be  on  the 
Generic  Identifier  position.  By  pressing  the  <PF13>  key  on  your 

keyboard,  the  form  will  change  to  that  of  the  parent  of  the 

element.  Reference  Section  4.4.2  Edit  a  DTD  for  examples  of  the 
commands  and  usage  of  this  form. 

4 . 2  .  1 . 2  .  3  Assign  Attribute 

This  action  within  the  Display  Document  Hierarchy  Menu  is 
used  to  assign  attributes  to  children  of  an  element.  Place  the 
cursor  on  the  child  of  the  element  that  you  wish  to  assign  an 
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attribute  to  and  press  the  <PF15>  key.  The  <PF15>  key  is  the 
Attribute  key  and  brings  in  the  Attribute  Form  of  the  Display 
Hierarchy  Form.  There  are  two  modes  in  this  form,  Insert  and 
Delete . 

The  Insert  mode  is  the  default  mode  for  this  form.  To 
insert  an  attribute  to  a  child  element,  place  the  cursor  on  an 
empty  Attribute  Input  Field.  The  attribute  should  be  entered 
into  this  input  field  and  the  <ENTER>  key  should  then  be 
pressed.  The  next  input  area  on  the  form  is  the  Default  Field. 
The  cursor  should  be  placed  on  this  field  and  the  data  typed  in 
along  with  the  <ENTER>  key.  The  next  input  area  is  the 
Associated  Values  Field  on  the  form.  The  cursor  should  be  moved 
to  that  input  field  and  the  data  entered  with  an  <ENTER> .  For 
examples  of  these  commands,  see  Section  4.4.2  Edit  a  DTD. 

4 . 3  Editing  a  DTD 

The  required  input  for  you,  the  user,  to  create  a  new 
document  type  definition  and  to  define  that  logical  structure  is 
the  E  (dit)  action  code  on  the  DTDBLD  main  menu  or  screen 
display.  There  is  no  difference  between  the  create  document 
type  and  the  edit  of  document  type.  To  create  the  document  type, 
dtdbld,  the  required  inputs  would  be  an  E  in  the  action  code 
field,  the  name  of  the  document  type  in  the  DTDname  field,  and 
the  pressing  of  the  <ENTER>  key.  Figure  4-6  illustrates  the 
inputs  for  this  step.  To  edit  that  same  DTD,  you  would  enter 
the  DTD  name  and  the  action  code  E  (dit)  on  the  first  input  line 
of  the  initial  screen  and  then  press  <RETURN>  or  you  would  move 
the  cursor  to  the  action  field  next  to  the  DTD  name  on  the 
screen  display  and  press  <RETURN>. 

4 . 4  Copy  DTD 

The  C  (opy)  command  is  an  action  to  be  used  when  you  wish 
to  create  a  similar  document  type  to  an  existing  one.  This  can 
be  beneficial  in  that  you  would  not  have  to  create  a  new 
document  type  from  the  very  beginning,  but  could  edit  a  copy  of 
a  similar  document  type.  Another  use  of  the  C  (opy)  action  is 
for  maintaining  the  previous  copy  of  a  revised  document  type. 

The  C  (opy)  action  is  entered  in  the  initial  EDSDTD  screen. 
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ED5  -  Documen:  Type  Definition  Builder  12/15/87  9:37:36  I 


DTD  Name  HjH  |  Action  (E,  D,  C,  S! 

Existing  DTD  Directory  Entries 

Action  DTD  Name  Description 

I  DTDBU) 

1 


!  From:  DTDBLD 


To: 


:1D5AV 


Description' 


hST 


appleationl 


Figure  4-9  C  (opy)  of  DTD 


A  message  will  appear  at  the  bottom  of  the  screen.  This 
message  will  require  input  form  you.  The  first  prompt  will  be 
for  the  name  of  the  new  file  and  the  second  prompt  will  be  the 
description  of  the  new  DTD  to  be  copied  into.  After  entering 
these  two  inputs,  press  the  <ENTER>  key. 
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The  C  (opy)  action  will  have  been  performed,  resulting  in 
the  following  form. 


[  £05  -  Oocuiier.:  Type  Definitior,  Builoer  ”  12/15/8T  12.26:36 

I 

DTC  Kaitie  |  Action  (£,  D,  C,  S! 

Existing  DTD  Directory  Entries 

'  A.::; O'.  DTD  Name  Description 

DTDSAV  nsi 
I  I  DTDBLD 


W 


applcationl 


Figure  4-10  C  (opy)  DTD  complete 


4 . 5  Delete  DTD 


The  D  (elete)  action  is  performed  similarly  to  the  C  (opy) 
action.  The  action  is  placed  in  the  action  field  for  the 
appropriate  DTD  and  the  <ENTER>  key  is  pressed.  D  (elete)  may 
also  be  performed  from  the  DTD  command  line.  The  action  is 
entered  on  that  line  along  with  the  DTD  name  and  the  <ENTER> 
key . 
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Figure  4-11  D  (elete)  of  a  DTD 


The  system  will  verify  that  the  selected  DTD  is  indeed  one 
to  be  deleted  from  the  system.  You  roust  enter  a  positive 
response  to  the  question  that  will  appear  if  you  wish  to  delete 
the  DTD.  The  displayed  roessage  will  appear  at  the  bottom  of 
your  screen.  You  must  respond  to  this  roessage: 


Okay  to  delete  Document  Type  Definition?  DTDname  Yes  No 


The  default  response  will  be  "YES"  and  can  be  entered  by 
pressing  the  <ENTER>  key.  The  screen  display  will  come  back 
without  the  deleted  DTD.  To  not  delete  the  selected  DTD  place 
the  cursor  on  the  **NO”  and  press  the  <ENTER>  key.  The  DTD  will 
not  be  deleted  and  the  screen  will  be  re-displayed  with  no 
action  taken. 
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SECTION  5 

LAYOUT  EDITOR  (EDSLE) 


This  section  will  explain  layout  structure  and  any 
additional  layout  tools  for  use  in  the  EDS.  Layout  or  format 
structure  is  the  physical  placement  of  the  document  text  on  the 
page.  In  any  document  there  are  certain  layout  requirements 
that  are  standard.  These  layout  or  format  requirements  range 
from  the  page  margins  to  the  space  between  lines  on  the  page. 

The  EDS  Layout  Editor  is  a  forms  based  program  that  enables 
you  to  define  the  layout  style  for  a  document  type.  The  layout 
style  is  defined  with  SGML  tags  within  a  document.  The  DTD  for 
the  document  must  be  defined  before  the  layout  style  can  be 
defined.  The  layout  style  (formatting  parameters)  that  you  -will 
define  for  the  DTD  will  be  the  Document  Profile. 

5 . 1  Layout  Requirements 

The  Document  Profile  is  the  set  of  formatting  commands  that 
you  will  give  the  Layout  Editor  for  the  DTD.  This  file  will 
contain  the  layout  style  for  the  logical  elements  of  the  DTD  and 
a  set  of  global  formatting  attributes  for  the  document. 

The  DTDBLD  component  of  EDS  builds  the  structure  of  the  document 
including  the  element  name.  The  Document  Profile  component  of 
EDS  builds  the  formatting  or  layout  style  parameters  for  the 
document  elements. 

Global  formatting  attributes  that  you  will  enter  into  the 
Layout  Editor  will  range  from  the  page  margin  requirements  to 
requirements  for  the  text  character  size  and  style. 

Additionally,  the  layout  style  for  the  logical  elements  of  the 
document  type  can  be  defined  in  the  creation  of  macros.  Macros 
are  a  set  of  layout  commands  for  a  specific  document  element. 

EDS  allows  you  to  create  macros  in  the  Layout  Editor. 

These  macros  are  the  format  or  layout  requirements  which  relate 
back  to  a  specific  generic  identifier.  For  example,  a  figure  in 
a  document  must  be  processed  in  specific  logical  steps.  The 
document  element  Figure  must  have  a  certain  amount  of  space 
reserved  for  it,  it  must  have  a  beginning  place,  and  an  ending 
place;  the  document  element  Figure  Number  must  be  centered  on 
the  page  along  with  the  figure  caption.  The  set  of  commands 
that  process  the  format  of  the  document  element  Figure,  are 
termed  macros. 
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5.2  The  Layout  Editor 


The  Layout  Editor  is  accessed  through  the  IISS  function 
menu.  You  must  log  into  the  IISS  with  a  valid  user  id  and 
account.  The  IISS  function  screen  should  appear,  you  must  enter 
EDSLE  in  the  Function  field  and  press  <ENTER>. 


The  next  screen,  or  form,  to  appear  is  the  initial  Layout 
Editor  Screen.  This  screen  will  display  in  a  list  format  the 
previously  defined  DTDs  and  any  previously  defined  Document 
Profiles.  There  may  be  several  Document  Profiles  to  a  single 
DTD.  These  multiple  profiles  can  be  used  with  the  same  document 
type  and  document  text  to  process  the  document  in  various  layout 
or  format  styles.  The  action  codes  that  are  available  in  this 
form  are  E  (dit) ,  C  (opy) ,  and  D  (elete) . 


Figure  5-1  Layout  Editor  Screen 


5.2.1  Create  Document  Profile 

To  create  a  Document  Profile  for  the  DTD  Unit  Test  Plan 
that  was  created  in  Section  4.4,  the  E  (dit)  action  code  must  be 
entered  in  the  Action  Field  on  this  form.  This  Action  Field  is 
located  to  the  left  of  the  DTD  name.  The  Document  Profile  name 
must  be  entered  also.  A  Description  Field  is  available  for  your 
use.  This  Description  Field  can  be  used  at  this  time  for  any 
description  that  you  wish  to  record  with  the  Document  Profile. 

It  should  be  noted,  this  field  can  be  modified  at  any  time. 

Let's  define  a  Document  Profile  to  the  DTD  Unit  Test  Plan 
that  you  defined  in  Section  4.4.  Place  the  cursor  on  the  Action 
Field  where  the  DTD  Unit  Test  Plan  is  listed  and  enter  an  'E'. 
Tab  the  cursor  over  to  the  Document  Profile  Field  and  enter  the 
profile  name,  'ICAMUTP'.  Tab  the  cursor  to  the  Description 
Field  on  the  form  and  enter  in  a  description  of  the  profile. 

You  might  enter  in  the  following: 
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ICAM  unit  test  plan  manual  12/87 


the  <ENTER>  key  for  the  system  to  process  your 
c^Ltio^ol  the  DocSment^Profile  IC^TP  tor  the  DTD  Unit  Tent 
Plan. 


IISS  Electronic  Oocuftcntotion  $yst«*  (EDS)  12/  4/S7  14:^3:26 


Layout  Editor 

Action  OTO  Nioc  Docuaent  Profile  Description 


□  [ 


onoooc 

20DI0 

SECOND  DEHO  DOCUMENT 

e 

OBMOOOC 

OEMODOC 

BtSUTP 

BDSLEl 

eds  layout  editor  utp 

ICAMOTP 

ICAHUTP 

ICAH  Unit  Test  Plan 

MSC:  [  0] _ _ _ _ _ applcation 

Figure  5-2  Document  Profile  Creation 


The  Document  Profile  is  created, 
pj'oceed  to  the  Layout  Editor  functions 
Profile. 


The  system  will  now 

for  tiiB  selected  Document 


5-3 


5 . 2 . 1 . 1  Layout  Editor  Function  Screen 


UM  620344900 
30  September  1990 


This  screen  form  will  be  the  one  from  which  you  select 
the  Layout  Editor  function  to  perform.  There  are  three 
functions  to  be  performed.  They  are  Page  Setup,  Generic  ID 
Layout,  and  Headers/Footers. 


IISS  Electronic  Docuacntition  Systes  (Layout  Editor) 

12/  4/87  15:07:34 

Henu 

Page  Setup 

Generic  ID  Layout 

Headers/Footers 

use:  fTl 

(pp)cation 

Figure  5-3  Layout  Editor  Function  Screen 


The  three  functions  that  are  performed  from  this  screen 
form  are  the  functions  necessary  to  define  the  layout  or  format 
of  the  document,  i.e.  the  Document  Profile.  The  following  is  a 
brief  description  of  these  functions. 

Page  Setup;  Definition  of  top  and  bottom  margins,  left 

and  right  margins  on  odd  and  even  pages, 
line  spacing,  leading  spaces,  font  size 
(pitch) ,  and  font  name  (type) . 


Generic  ID  Layout:  Definition  of  format  parameters  for  the 

elements  of  a  document,  i.e.  build  of 
relationship  between  a  generic  id  and  its 
layout  stlye 
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Headers/Footers:  Definition  of  the  reserved  area  at  the  top 

and  the  bottom  of  the  page  of  a  document  for 
additional  document  information. 

The  functions  are  selected  from  the  form  by  placing  the  cursor 
on  the  function,  use  the  <TAB>  key,  and  pressing  the  <ENTER> 
key.  Each  function  selected  goes  into  a  subordinate  form. 

Let's  begin  with  Page  Setup. 


IISS  electronic  Oocuaentetlon  System  (Layout  Editor)  12/  4/67  15:07:45 

Psge  Setup  for  Document  Profile  DENODOC 


Hargins 


Top 

~.oo 

IN 

Line  Spacing 

Bottoo 

1.00 

IN 

Leading 

u 

(Evtn) 

]  .00 

IN 

font  Size 

12 

Right 

1.00 

IN 

Font  Name 

Times-Roman 

(Odd)  Left 

1.00 

IN 

Right 

1.00 

IN 

HSC:  [  o  f _  applcat  Ion  | 


Figure  5-4  Page  Setup  Screen 


5. 2. 1.1.1  Page  Setup 

The  Page  Setup  function  is  the  function  that  you  will  use 
for  the  margins,  line  spacing,  leading  spaces,  and  font 
characteristics.  The  Screen  displays  the  Document  Profile  that 
you  are  editing  and  the  input  fields  for  the  Page  Setup 
Function.  Default  assignments  are  already  in  place  for  these 
input  fields.  Changes  can  be  made  to  each  input  field  by  moving 
the  cursor  to  the  field  and  typing  in  the  desired  change.  The 
input  fields  are: 
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Top  Margin:  This  parameter  is  used  to  reserve  space  at 

the  top  of  the  page  for  a  margin.  Its  value 
can  be  expressed  in  inches,  centimeters, 
characters,  etc. 

Bottom  Margin:  This  parameter  is  used  to  reserve  space  at 

the  bottom  of  the  page  for  a  margain.  Its 
value  can  also  be  expressed  in  inches, 
centimeters,  characters,  etc. 

Even  Left  Margin:  This  parameter  is  the  left  margin  space  for 

an  even  numbered  page.  Its  value  can  be 
expressed  the  same  as  the  other  margins. 

Even  Right  Margin:  This  parameter  is  the  right  margin  space 

reserved  for  an  even  numbered  page.  Its 
value  can  be  expressed  the  same  as  the  other 
margins . 

Odd  Left  Margin:  This  parameter  is  for  the  reserved  left 

margin  space  for  an  odd  numbered  page.  Its 
value  can  be  expressed  the  same  as  the  other 
margins . 

Odd  Right  Margin:  This  parameter  is  for  the  reserved  right 

margin  space  for  an  odd  numbered  page.  Its 
value  can  be  expressed  the  same  as  the  other 
margins . 

Line  Spacing:  This  value  is  usually  expressed  in  inches. 

A  value  of  2.00  would  be  two  lines  or  double 
spaced . 

Leading:  This  value  is  expressed  in  the  amount  of 

space  between  a  characters  printed  on  the 
page . 

Font  Size:  This  value  is  expressed  in  the  size  or  pitch 

of  a  character,  i.e.  10,  12,  14. 

Font  Name:  This  value  is  expressed  in  a  name  of  a  font 

type  or  style.  The  supported  fonts  for  the 
EDS  are  maintained  for  you.  The  <HELP>  key 
will  produce  a  list  of  available  fonts  while 
on  this  input  field. 

After  the  changes  have  been  made  to  the  input  fields,  press 
the  <ENTER>  key  to  save  the  changes.  The  System  will 
redisplay  the  screen  with  the  new  values. 

In  order  to  go  on  to  the  next  function,  you  must  press  the 
IISS  QUIT  key,  <PF4>,  this  will  take  you  back  to  the  Layout 
Editor  Function  Screen.  You  can  now  select  another  function  by 
placing  the  cursor  on  the  selected  function  and  pressing  the 
<ENTER>  key.  Let'  ro  to  the  Generic  ID  Layout  Screen. 


5-6 


\ 


UM  620344900 
30  September  1990 


5. 2. 1.1. 2  Generic  Identifier  Layout 

The  Generic  ID  Layout  Screen  displays  the  DTD  and  the 
Document  Profile  at  the  top  of  the  form.  This  screen  also 
displays  the  Generic  Identifier  that  was  defined  in  the  CT’D  and 
the  macro  name  of  that  Generic  Identifier.  You  must  select  a 
macro  from  the  displayed  list  to  change  the  layout  style  of  that 
macro.  Place  the  cursor  on  a  macro  name  in  the  listed  area  on 
the  form  and  press  <ENTER>.  This  action  will  take  us  to  the 
Format  Attribute  Form  for  the  selected  macro.  If  no  action  is 
desired,  the  IISS  QUIT  key,  <PF4>,  would  quit  this  form  and  go 
back  to  the  Layout  Editor  Function  Screen. 

llSS  tl.tlto.ic  Doei».nt«Iloi>  $>■•••  (Urout  Uliot)  IjTTTil  BTSTB*  I 

OTO  ;  OMOOOC 
0o(u*c>^<  Pcolil*  •  OmoOOC 

Fully  0w•l»^>td  C«r»*iU 


OCROOOC 
OCMOOOC .  ftOOT 
ocnoooc  iOOT.LIST 
ocnocxtc . tOOT .LIST  ITER 
oeiioooc .  iool .  ricuu 

OBMODOC .  »0D1 .  riCUM  f ICOESC 
OCROOOC .  coot .  f ICUEt.  FICPCSC  flCTXTU 
OCROOOC .  OOOT  f ICUW .  FlCDtSC  HOW 
OCROOOC .  OOOT .  f  1  CURE .  FXCOCSC  -  fl9tf 

OCROOOC  -  tODI .  ri  CURE .  REfOrr 

OCROOOC .  COOT .  riCUCC .  CRAFRI  c 
OCMOOOC  ROOl .  riCURE  rtCCODT 

ra - — - 


Ractft  N*»« 


SOIRPDO 

SaODT 

sljst  j 
SJTtn  I 

SnCURE  i 
SPlCOtS  \ 
SF1CT1t|  I 
sricNUf*;  , 
sriCRtr  j 
SHtPOFT,  . 
sncTiij 
sncsor 


nor» 

•p^lc•l  ier> 


Figure  5-5  Generic  Id  Format  Attribute  Form 

This  form  has  no  default  values  assigned  to  it.  The  input 
fields  on  the  form  must  be  tabbed  to  using  the  <TAB>  key  and 
enter  the  data.  Input  field  values  vary  on  this  form: 


Bold : 


Underline : 


Reverse : 


Italics: 


No  Break: 


This  is  used  to  define  the  Generic  ID  as 
boldface  type  on  the  page.  An  'x' 
indicates  the  field  is  selected.  A 
blank  in  the  field  is  considered  an  'N'. 

This  is  used  to  define  the  Generic  ID  as 
underlined  type  on  the  page.  This  has 
the  same  values  as  Bold. 

This  is  used  to  define  the  Generic  ID  as 
a  reversed  print  on  the  page,  i.e.  print 
is  white  on  black.  An  'x'  indicates  the 
field  is  selected,  a  blanks  indicates 
not  selection. 

This  is  used  to  define  the  print  style 
of  the  Generic  ID  as  italic.  Values  are 
a  'x'  for  yes  or  blank  for  no. 

This  is  used  to  define  whether  or  not 
the  GI  is  to  span  multiple  pages. 

Values  are  a  'x'  for  yes  or  blank  for 
no. 
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Literal : 


No  Advance; 


Justify  Center: 


Justify  Right: 


Justify  Full: 


Indent  Left: 


Indent  Right: 


Indent  1st  Line 


Vertical  Space 


This  is  used  to  define  whether  or  not 
the  Generic  ID  is  a  literal.  Values  are 
'x'  for  yes  or  blank  for  no. 

This  is  used  to  define  whether  or  not 
the  Generic  ID  causes  an  advance  line 
after  being  processed.  Values  are  'x' 
for  yes  or  blank  for  no. 

This  is  used  to  define  whether  or  not 
the  Generic  ID  is  justified  to  the 
center  of  the  defined  page.  Values  are 
'x'  for  yes  or  blank  for  no. 

This  is  used  to  define  whether  or  not 
the  Generic  ID  is  justified  to  the  right 
of  the  defined  page.  Values  are  'x'  for 
yes  or  blank  for  no. 

This  is  used  to  define  whether  or  not 
the  Generic  ID  is  justified  between  the 
left  and  right  margins  of  the  defined 
page.  Values  are  'x'  for  yes  or  blank 
for  no. 

This  is  used  to  define  the  Generic  Id  to 
be  indented  on  the  left  side  of  the 
page.  Values  are  expressed  in  inches, 
centimeters,  or  character  spaces. 

This  is  used  to  define  the  Generic  Id  to 
be  indented  on  the  right  side  of  the 
page.  Values  are  expressed  in  inches, 
centimeters,  or  character  spaces. 

:  This  is  used  to  define  the  first  line  of 

the  Generic  Id  to  be  indented  on  the 
left  side  of  the  page.  Values  are 
expressed  in  inches,  centimeters,  or 
character  spaces. 

Before:  This  is  used  to  define  whether  or  not 

the  Generic  ID  is  processed  with 
vertical  space  before  it  is  placed  on 
the  defined  page.  Values  are  expressed 
in  inches,  centimeters,  or  character 
spaces , 
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Vertical  Space  After:  This  is  used  to  define  whether  or  not 

the  Generic  ID  is  processed  with 
vertical  space  after  it  is  placed  on  the 
defined  page.  Values  are  expressed  in 
inches,  centimeters,  or  character 
spaces . 

Horizontal  Space  Before:  This  is  used  to  define  whether  or  not 

the  Generic  ID  is  processed  with 
horizontal  space  before  it  is  placed  on 
the  defined  page.  Values  are  expressed 
in  inches,  centimeters,  or  character 
spaces . 

Horizontal  Space  After:  This  is  used  to  define  whether  or  not 

the  Generic  ID  is  processed  with 
horizontal  space  before  it  is  placed  on 
the  defined  page.  Values  are  expressed 
in  inches,  centimeters,  or  character 
spaces . 

Page  Eject  Before:  This  is  used  to  define  whether  or  not 

the  Generic  ID  has  a  page  ejected  before 
it  is  presented  on  the  page.  Values  are 
expressed  in  integer  number  of  pages  or 
blank. 

Page  Eject  After:  This  is  used  to  define  whether  or  not 

the  Generic  ID  has  a  page  ejected  after 
it  is  presented  on  the  page.  Values  are 
expressed  in  integer  number  of  pages  or 
blank. 

Font  Size:  This  is  used  to  define  the  Generic  ID 

with  a  specific  font  size  other  than  the 
one  specified  for  the  entire  document. 

Leading:  This  is  used  to  define  the  Generic  ID 

vjith  any  special  spacing  requirements 
between  characters  other  than  those 
specified  for  the  entire  document. 
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Line  Spacing: 


Font  Name: 


This  is  used  to  define  the  Generic  ID 
with  special  line  space  requirements 
other  than  those  specified  for  the 
entire  document.  Value  is  expressed  in 
number  of  lines. 

This  is  used  to  define  a  special  font 
type  or  style  for  the  Generic  ID  other 
than  that  specified  for  the  entire 
document.  The  <HELP>  key  will  list 
available  fonts  for  your  use. 


After  all  of  the  selected  attributes  for  the  selected 
Generic  ID  have  been  changed,  press  <ENTER>  to  save  the  Document 
Profile  and  return  to  the  Generic  Identifier  Screen.  Another 
Generic  Identifier  can  be  selected  from  this  screen  for 
attribute  definition  by  placing  the  cursor  on  the  selected 
Generic  ID  and  pressing  <ENTER>.  However,  to  quit  this  form  you 
must  press  the  IISS  QUIT  key  <PF4>.  The  <PF4>  key  will  act  as  a 
quit  key  in  all  of  these  forms  and  will  take  you  back  to 
the  previous  form. 

5.2.1. 1.3  Headers/ Footers 

This  is  the  third  function  of  the  Layout  Editor.  Place  the 
cursor  on  the  field  and  press  <ENTER>.  The  Header/Footer  Form 
will  appear  on  your  screen. 


IISS  (Itcrenic  0e<u**ni«tien  Syf(t»  (Uyew(  Cdiior)  12/  «/t7  15:M:62 


(run<Uor)  OvdrMr 
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Odd 
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■on 


Iff*  ol  Hoadvrs^foettrs 
N««d€r /Footer 
POOTKfl 


Figure  5-6  Header/Footer  Form 


The  input  fields  on  this  form  are  similar  to  some  of  the 
fields  you  have  seen  on  the  other  Layout  Editor  screen  forms. 
The  initial  input  fields  are: 

Function:  Define  or  Delete  of  header  or  footer 
Page  Side:  Even  or  Odd  or  Both  of  the  pages 
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Position: 


Top  (header)  or  Bottom  (footer)  of  the 
page 


After  you  have  selected  the  Function,  the  Page  Side,  and  the 
Position;  press  the  <ENTER>  key.  This  will  complete  the  form 
for  the  selected  Function  and  Position.  A  Define  Function  will 
display  the  rest  of  the  form.  For  example,  if  the  Define 
Function  and  the  Top  Position  was  selected,  the  following  form 
would  appear.  _ 


IISS  Eltctronic  Docuffi«nt4iioit  System  (Layout  Editoi) 


Meadets/Footers 


12/  */07  ’5:13:19 


( Func l iOA) 

Define 
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(Face  Side) 

£wan 

Add 

( Fosu  ion) 

Top 

fiottoa 

{loa  Top 

0.  jO 

Iti 

Stan  (at)  TAG 

Proa  Sottoa 

Left  Hargin 

Reset  Page  (at)  TAG 

Right  Hargin 

Styla 

Contar 

n 

Right  Justify  (7) 

Pontsiza 

1 

Underline  [ j 

Leading 

L 

Fontnaaa 

_ 

Text 

Lina  (1)  1 

EOS  Oaaonstcation 

Lina  (2)  | 

Arizona  Stata  University 

Lina  (3) 

loacenbar 

7. 

1987 

nsc: 


applcation 


Figure  5-7  Header/Footer  Form  -  Define 


Input  fields  and  their  meanings  follow: 

from  Tod:  The  value  in  inches,  centimeters,  or 

character  spaces  that  the  header  is  from 
the  top  of  the  page. 

from  Bottom:  The  value  in  inches,  centimeters,  or 

charater  spaces  that  the  footer  is  from 
the  bottom  of  the  page. 


Left  Margin: 


Right  Margin: 


Start  (at)  Tag: 


The  value  in  inches,  centimeters,  or 
character  spaces  the  header  or  footer  is 
from  the  left  side  of  the  page. 

The  value  in  inches,  centimeters,  or 
character  spaces  the  header  or  footer  is 
from  the  right  side  of  the  page. 

The  tag  name  where  the  header  or  footer 
is  to  start. 


Reset  Page  (at)  Tag:  The  tag  name  where  the  page  number 

counter  would  be  reset  to  one. 
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Style  Center: 

Style  Font  Size: 

Right  Justify: 

Underl ine : 

Style  Leading: 

Style  Font  Name: 

Text  Line  ( 1 ) : 
Text  Line  ( 2 ) : 
^’ext  Line  (3)  : 
Text  Line  Macros: 


Whether  .ot  the  header  or  footer  is 

centered  ^n  the  page.  Value  is  'x'  for 
yes  or  blank  for  no. 

The  size  of  the  font  for  the  header  or 
footer  is  specified  here  and  would  be 
different  than  that  specified  for  the 
entire  document. 

This  defines  the  header  or  footer  to  be 
right  justified.  Value  is  'x'  for  yes 
or  blank  for  no. 

This  defines  the  header  or  footer  to  be 
underlined.  Value  is  'x'  for  yes  or 
blank  for  no. 

The  definition  of  spacing  requirements 
for  the  characters  printed.  Expressed 
in  an  integer  number  for  point  size. 

The  name  of  the  font  for  the  header  or 
footer  if  different  from  that  of  the 
entire  document  would  go  here. 

This  is  a  line  for  text  input  of  the 
header  or  footer. 

This  is  a  line  for  text  input  of  the 
header  or  footer. 

This  is  a  line  for  text  input  of  the 
header  or  footer 

@page  -  to  invoke  header/ footer  on  a 
specific  page 

0time  -  to  print  the  computer  system 
time  in  the  header/footer 

@date  -  to  print  the  computer  system 
date  in  the  header/ footer 

^counter  <tag>  -  to  count  and  print  the 
number  of  occurrences  of  the  specified 
tag 


The  input  fields  are  tabbed  to  and  after  all  selected 
fields  have  been  changed,  the  Document  Profile  is  saved  by 
pressing  the  <ENTER>  key.  The  screen  form  will  he  redisplayed 
with  the  new  input  fields.  The  IISS  QUIT  key  <PF4>  will  take 
you  back  to  the  previous  screen  form.  That  form  should  be  the 
Layout  Editor  Function  Screen. 

The  input  fields  for  the  footer  definition  are  virtually 
the  same  as  that  of  the  header  definition.  The  delete  of  a 
header  or  a  footer  is  accomplished  in  the  same  way  as  that  of  a 
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define  function. 

5.2.2  Edit  Document  Profile 

To  edit  a  Document  Profile  for  a  DTD,  the  E  (dit)  action 
code  must  be  entered  in  the  Action  Field  on  this  form.  This 
Action  Field  is  located  to  the  left  of  the  DTD  name  with  the 
selected  Document  Profile.  The  Description  Field  is  not 
available  for  your  use.  It  should  be  noted,  that  Document 
Profile  creation  is  the  only  time  that  the  Description  field  can 
be  entered. 

The  edit  of  a  Document  Profile  is  similar  to  the  creation 
of  a  Document  Profile  in  that  the  same  forms  are  used.  The  E 
(dit)  action  on  an  existing  Document  Profile  displays  the 
previously  defined  information.  You  can  then  perform  the 
necessary  edits  to  that  information  in  the  Layout  Editor  forms. 
Place  the  cursor  on  the  Action  Field  where  the  DTD  Unit  Test 
Plan  is  listed  and  enter  an  'E'. 

Now  press  the  <ENTER>  key  for  the  system  to  process  your  E  (dit) 
action  on  the  selected  DTD  Document  Profile. 
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liSS  Eieclronic  Docuientalion  Systca  (EDS)  11/  1/87  15  32:24 
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Figure  5-8  Edit  Document  Profile 


The  system  will  now  proceed  to  the  Layout  Editor  functions 
for  the  selected  Document  Profile.  Reference  Section  5.2.2  for 
discussion  and  explanation  of  the  Layout  Editor  Function  Screen 
and  all  subordinate  screen  forms  and  functions. 

5.2.3  Copy  Document  Profile 

The  C  (opy)  action  of  the  Layout  Editor  Screen  is  dependent 
on  the  forms  for  that  one  screen  alone.  You  will  want  to  use 
the  C  (opy)  action  to  reduce  Document  Profile  edit  time. 

Copying  a  Document  Profile  and  then  editing  that  profile  will  be 
a  more  efficient  use  of  the  system  than  creating  new  Document 
Profiles.  This  is  especially  true  of  the  highly  structured 
documentation  standards  that  exist  on  many  projects  and  in  the 
industry.  A  copy  of  an  existing  Document  Profile  is 
accomplished  with  these  steps.  Place  the  cursor  on  the  Action 
Field  on  the  same  line  as  the  DTD  and  Document  Profile  that  you 
wish  to  copy.  Enter  a  'C  in  that  Action  Field  and  press  the 
<ENTER>  key,  see  the  next  figure. 
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IISS  Electronic  Docunentat ion  Sysle«  (EOS)  llT 6/87  15:35:46 

Layout  Editor 
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I  K30:  B _ applcatiorj 

Figure  5-9  Layout  Editor  Screen  -  Copy 


An  additional  form  will  appear  on  the  Editor  Layout  Screen. 
This  form  will  have  three  input  fields  on  it.  These  input 
fields  are  Source  Document  Profile  (DP) ,  Destination  DP,  and 
Description  of  Destination  DP.  You  must  tab  the  cursor  over  to 
these  fields  and  input  the  data.  The  Source  DP  is  the  Document 
Profile  you  are  making  a  copy  of.  The  Destination  DP  is  the  new 
file  that  you  are  creating  in  this  C  (opy)  action.  The 
Description  field  is  the  information  field  for  the  Destination 
DP.  After  you  have  entered  this  information  into  the  input 
fields,  press  <ENTER>  to  execute  the  action. 

The  Layout  Editor  Screen  will  redisplay  with  the  new 
Document  Profile  in  the  displayed  list  of  Document  Profiles. 

The  <PF4>  will  cancel  or  quit  this  screen  at  any  time. 
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Figure  5-10  Editor  Layout  Screen  -  After  Copy 


5.2.4  Delete  Document  Profile 


The  D  (elete)  action  on  the  Layout  Editor  Screen  is 
performed  in  a  similar  fashion  to  the  C  (opy)  action. 

The  D  (elete)  action  of  the  Layout  Editor  Screen  is  dependent  on 
the  forms  for  that  one  screen  alone.  You  will  want  to  use  the  D 
(elete)  action  when  a  document  profile  is  no  longer  current.  A 
delete  of  an  existing  Document  Profile  is  accomplished  with 
these  steps.  Place  the  cursor  on  the  Action  Field  on  the  same 
line  as  the  DTD  and  Document  Profile  that  you  wish  to  delete. 
Enter  a  'D'  in  the  Action  Field  and  press  the  <ENTER>  key,  see 
the  next  figure. 
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Figure  5-11  Layout  Editor  Screen  -  Delete 


An  additional  form  will  appear  on  the  Editor  Layout  Screen. 

This  form  will  have  verify  the  intent  to  delete.  A  question  will 
appear: 

OK  to  delete  Document  Profile  ?  DPname  YES  NO 

The  system  has  a  default  assignment  for  the  question's  answer. 
That  default  is  the  'YES'.  A  press  of  the  <ENTER>  key  would 
complete  the  D  (elete)  action.  The  Layout  Editor  Screen  would 
redisplay  and  the  DP  that  was  deleted  would  no  longer  be  on  the 
displayed  list. 
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IISS  Electronic  Oocunentalion  Syslci  (EDS)  Tl/  i/81  15;25;20 


Layout  Bdiior 

Action  DTD  Nano  Oocuoent  Profile  Description 
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1  _  _ _ 

Figure  5-12  Layout  Editor  Screen  -  After  Delete 

However,  if  you  do  not  want  to  delete  the  DP,  you  must  tab  to 
the  second  response.  By  placing  the  cursor  on  "NO’  and  pressing 
the  <ENTER>  key,  you  would  stop  the  D  (elete)  action.  Again,  a 
<PF4>  key  would  quit  the  screen  form  and  return  you  to  a 
previous  screen. 
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SECTION  6 
SGML  PARSER 


6 . 1  Parsing  for  SGML 

The  SGML  Parser  is  the  component  of  the  EDS  that  validat-c 
the  logical  structure  of  a  document  against  a  a  SGML  Document 
Type  Definition.  The  SGML  Parser  was  first  implem'^nted  under 
the  MS-DOS  environment  by  the  National  BureCv^  cl  Standards 
(MBS) .  The  Parser  was  ported  or  migrated  from  the  MS-DOS 
environment  to  the  IISS.  Portions  of  the  code  were  changed  to 
enhance  its  functionality  in  the  EDS. 

The  validation  process  of  the  Parser  ensures  that  the 
descriptive  markup  used  within  the  document  to  delimit,  or  tag, 
the  logical  structures  conforms  to  the  set  of  rules  defined  by 
the  DTD.  These  rules  determine  what  tugs  are  valid  and  how  many 
times  a  SGML  tag  occurs  within  a  document.  Additionally,  the 
Parser  converts  the  document  to  its  fully  "marked  up"  state  by 
processing  all  Entity  references  and  expanding  all  minimized 
tags  found  within  the  document. 

G . 2  Running  the  Parser 

The  execution  of  the  SGML  Parser  is  accomplished  by 
entering  a  set  of  commands  on  the  command  line.  These  commands 
involve  invoking  the  Parser,  naming  the  source  document  text 
file,  assigning  a  file  name  for  the  SGML  marked  up  file,  and 
pressing  the  <return>  key.  The  command  structure  is: 


sgml  -of  1 lename 1 . ext  edsdtl ib ; dtdname . dtd  f ilenarae2 . ext 


return> 

sgml  -o 

Invokes  the  Parser 

t i 1  enamel . ext 

This  is  the  output  file  name  of  the  marked 
up  file  with  extension  name  after  parsing 
the  document  for  SGML  tags. 

edsdtl ib ; 

This  is  the  EDS  logical  name  for  the 
directory  v.'here  the  DTDs  are  located. 

dtdname . dtd : 

This  is  the  DTD  that  is  defined  in  the  above 
directory  with  a  .dtd  extension  type. 

f  L  lenar>G2  .  ext 

This  is  the  name  of  the  document  text  file 
with  extension  name,  i.e.  edsdemo.doc 

■  retu  rn  > 

This  is  the  final  input  for  the  processiny) 
of  a  command  to  the  computer  system. 
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The  Parser  will  not  resolve  the  inclusion  of  graphics  files. 
However,  a  fully  marked  up  SGML  document  will  be  the  Parser's 
output  ( f ilenamel . ext  from  above). 

Any  errors  detected  during  the  parsing  of  the  document  will 
be  noted  by  the  Parser.  These  errors  will  cause  the  Parser  to 
return  error  messages  to  the  screen  display  showing  the  errors 
that  occurred  and  an  approximation  of  where  the  errors  occurred. 
The  marked  up  file  will  not  exist  if  errors  were  '  ^tected  during 
parsing.  These  errors  must  be  fixed  in  order  to  arse  the 
document  text  file.  After  the  errors  have  been  corrected,  the 
Parser  must  be  invoked  again.  Only  a  cleanly  parsed  docum.ent 
can  continue  to  the  formatting  stage  of  the  EDS. 
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SECTION  7 
TAGGER 


7 . 1  Tagging  a  File 

The  tagging  or  "marking  up"  of  a  text  file  for  processing 
into  a  document  is  done  in  the  specific  text  processing  system 
that  is  available.  EDS  allows  for  tagging  a  document  in  the 
text  when  creating  or  editing  an  EDS  document.  However,  there 
are  many  documents  that  are  not  EDS  documents  that  may  be 
converted  to  EDS.  This  conversion  is  accomplished  with  the 
Tagger . 

The  SGML  Tagger  enables  you  to  specify  a  translation 
between  a  document  in  word  processing  format  to  an  SGML  tagged 
document.  A  translation  program  must  be  built  for  each  unigue 
word  processor  and  document  type  definition  that  will  be  used  to 
process  documents.  A  forms-driven  interface  is  provided  to 
assist  in  the  pattern  matching  type  statements  that  define  the 
mapping  between  word  processor  formatting  codes  and  document 
content  to  SGML  tags.  These  statements  are  used  as  input  for  a 
generated  LEX  program  that  performs  the  actual  translation  of 
the  word  processing  document. 


7 . 2  Document  Markup 

Markup  is  a  set  of  text-like  commands  that  is  added  to  the 
data  of  a  document  to  imply  information  about  the  data  of  the 
document.  Each  significant  element  of  the  document  is  located 
and  marked,  thus  the  term  markup,  with  a  mnemonic  name.  This 
mnemonic  name,  the  generic  identifier  (GI) ,  is  then  associated 
with  that  document  element.  The  definition  of  a  document 
element  and  its  mnemonic  is  accomplished  in  the  DTDBLD  component 
of  the  EDS.  This  Document  Type  Definition  (DTD)  is  used  to 
ensure  the  source  document  conforms  to  the  logical  structure 
defined  for  it. 

The  GI  has  a  specific  syntax  associated  with  it.  The  start 
or  beginning  tag  of  a  GI  is  delimited  by  the  less-than  symbol 
(<)  and  to  complete  the  tag  the  delimiter  greater-than  symbol 
(>).  The  ending  delimiter  to  a  tag,  either  the  start  or  end 
tag,  separates  the  GI  from  the  actual  text  of  the  document. 
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With  the  use  of  a  start  tag  for  the  mnemonic  there  may  also  be 
an  end  tag.  The  beginning  of  the  end  tag  is  delimited  by  the 
less-than  symbol  followed  by  the  solidus  symbol  (</). 

Document  Element  =  Generic  Identifier  (GI,  mnemonic 

name) 

GI  includes: 

<start  tag> 

</end  tag> 

Figure  7-1  Generic  Identifier  in  Markup 

The  GI  or  document  element  is  only  identified  in  the  above 
structure . 

The  physical  presentation  characteristics  of  the  GI  is 
generated  separately.  Establishing  the  relationship  between  the 
document  element  or  GI  (logical  structure)  and  the  physical 
characteristics  for  that  GI  (layout  style)  are  accomplished  in 
the  Layout  Editor  component  of  the  EDS. 

The  processing  of  the  source  document  text  with  the  Gis  and 
their  layout  styles  is  verified  with  another  EDS  component. 

That  component  is  the  SGML  Parser.  The  Parser  validates  the 
source  document  with  its  defined  logical  structure  without 
processing  the  source  document.  The  Parser  reads  the  GIs, 
recognizes  the  Gis,  and  inserts  those  tags  associated  with  the 
GI  into  the  parsed  file. 

The  Formatter  is  then  run  to  complete  the  processing  of  the 
document.  The  parsed  document  file  is  mapped  to  the  physical  or 
layout  characteristics  to  create  the  final  form  of  the  document 
which  is  generated  in  Postscript. 

7.2.1  Manual  Document  Markup 


The  manually  marking  up  of  a  source  document  is 
accomplished  by  you  or  by  the  authors  of  the  source  content. 
This  writing  of  source  content  for  the  document  can  be  done 
using  any  text  editor  available  to  you.  EDS  does  not  rely  on 
any  particular  text  editor.  Any  word  processing  file  can  be 
converted  for  use  by  EDS,  see  Section  7.3. 
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The  marking  up  of  a  source  document  follows  the  basic 
concepts  of  document  elements.  We  have  defined  a  document 
structure  in  Section  4.0.  Those  identified  elements  have  been 
placed  within  a  logical  structure  of  the  document  type.  Those 
elements  have  been  given  names  (GI)  for  use  as  reference  back  to 
the  individual  document  elements.  It  is  these  mnemonic  names 
that  are  used  in  the  marking  up  of  a  source  document. 

You  have  entered  these  names  in  the  DTDBLD;  have  defined 
the  format  parameters  for  them  in  the  Layout  Editor.  Many  of 
these  SGML  tags  are  apparent  to  you.  For  example: 

for  coverpage  the  SGML  tag  is  <covpg> 
ending  tag  is  <\covpg> 

for  a  paragraph  the  tag  is  <p0> 
ending  tag  is  <\p0> 

for  a  major  section  tag  the  mark  up  would  be 
<sect> 

<sectno>SECTION  7<\sectno> 
<sectnm>TAGGER<\sectnm> 

for  subsequent  sections  to  the  major  section 

<chap> 

<chapno>7 . l<\chapno> 

<chapnm>Tagging  a  File<\chapnm> 

The  actual  document  markup  that  you  would  do  is  predicated 
on  your  defined  document  structure.  For  further  reference  on 
the  marking  up  of  a  document,  see  ISO  8879  and  Appendices  A 
through  C  of  this  document. 

7 . 3  Automated  Document  Markup 


Typically,  word  processing  files  contain  both  logical  and 
layout  structure  information.  Formatting  codes  (character 
sequences)  are  used  to  represent  logical  (example,  paragraph) 
and  layout  (example,  page  break)  information  within  the 
document.  In  order  to  tag  a  document,  certain  formatting  codes 
are  used  to  generate  SGML  tags  when  they  are  encountered.  For 
example,  if  all  section  titles  in  a  document  were  always 
centered  and  underlined,  then  a  specification  statement  used  by 
the  Tagger  would  be  feasible.  This  statement  would  be  processed 
when  the  character  sequence  for  center  and  underline  is 
recognized.  The  statement  would  write  a  tag  to  the  former  word 
processing  file. 
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Along  with  the  formatting  codes,  the  actual  content  of  a 
document  can  be  used  to  generate  SGML  tags.  For  example,  a  user 
can  specify  that  the  character  sequence  section  number  is 
recognized.  The  section  number  sequence  will  cause  a  section 
number  to  be  written  to  the  file.  Specifications  using  a 
combination  of  content  and  formatting  codes  are  also  possible. 

In  addition  to  the  forms-driven  interface,  the  Tagger 
consists  of  a  lexical  writer,  a  run-time  processor,  and  a 
specification  storage  program.  Once  all  specification 
statements  are  entered  and  validated,  the  Tagger  begins  the 
lexical  writer.  Autotag,  to  produce  a  valid  LEX  program.  This 
LEX  program  corresponds  to  the  specification  of  the  components 
supplied  by  the  user.  These  components  are  the  formatting 
commands  of  the  unique  word  processor.  The  run-time  processor 
runs  the  LEX  to  produce  a  C  program  from  the  specification  file, 
compiles  the  result,  and  links  it  with  the  main  program  of  the 
Tagger.  The  main  program  is  used  to  tag  a  word  processing 
document . 

After  the  document  has  been  tagged,  it  is  sent  to  the 
Parser.  The  output  of  the  Parser,  the  error  report,  provides  an 
indication  as  to  how  well  the  document  has  been  tagged.  The 
Parser  inserts  end  tags  in  the  document  by  using  the  DTD 
information  to  decide  when  the  tag  is  ended.  Any  necessary 
corrections  to  this  newly  tagged  and  parsed  document  can  then  be 
made . 


Use  of  the  Tagger  and  its  components  will  not  ensure  that 
the  document  will  be  completely  and  correctly  tagged  for  SGML. 
The  efficiency  of  the  translation  from  word  processor  to  SGML  is 
dependent  on  the  number  of  defined  patterns  that  can  be 
interpreted  to  generate  SGML  tags.  Forethought  should  be  used 
in  the  development  of  these  tools  for  this  conversion  process. 

7 . 4  The  Tagger 

The  Tagger  is  used  in  the  IISS  for  the  initial  definition 
of  a  specification  type.  This  specification  is  defined  in  the 
Autotag  program  of  the  Tagger.  To  use  the  run-time  processor 
and  the  Tagger,  it  is  not  necessary  to  be  in  the  IISS. 

7.4.1  Autotaq 

This  EDS  utility  will  create  and  generate  a  tagger 
specification  for  SGML.  The  user  must  be  able  to  understand  the 
command  structure  of  the  word  processing  system  that  the 
specification  will  be  built  for.  You  must  log  into  the  IISS 
v;ith  a  valid  user  id  and  account.  The  IISS  Function  Screen  v.'ill 
be  the  next  screen  to  appear.  Place  the  cursor  on  the  Function 
field,  type  in  'Autotag',  and  press  the  <ENTER>  key. 
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The  next  screen  form  will  be  that  of  the  Autotag  utility. 
The  functions  available  for  Autotag  are  listed  on  the  screen  as 
illustrated  in  the  next  figure. 


Figure  7-2  Autotag  -  IISS  SGML  Auto  Tagging  Facility 

The  name  of  the  specification  file  that  you  will  define  or 
edit  must  first  be  typed  in.  This  name  will  be  typed  into  the 
field  for  the  Auto  Tag  Definition  File.  After  entering  the  file 
name  and  pressing  the  <PF16>  key  (LOAD) ,  the  file  you  entered 
will  be  loaded  for  use  in  the  Tagger  specification  forms.  The 
<ENTER>  key  will  load  the  specification  file  into  the  system  for 
you  if  that  file  exists.  If  a  new  specification  is  being 
started  the  template  file  for  the  appropriate  word  processor 
must  be  loaded.  When  <ENTER>  is  pressed  the  file  is  saved.  The 
functions  available  to  you  are: 

PF5  State  Definition 

PF6  Character  Class  Definition 

PF7  Pattern/Action/State  Definition 

PF8  C  Declarations 

PF16  Save  Auto  Tag  Definition  File 

Each  function  has  a  Program  Function  (PF)  Key  defined  to 
it.  By  pressing  the  PF  Key  for  the  desired  specification  (or 
function)  you  will  only  have  to  press  a  single  key. 

Each  of  the  specification  screens  operate  in  a  consistent 
manner.  Each  screen  has  a  field  at  the  top  for  entering  new 
data,  a  field  at  the  bottom  of  each  group  to  indicate  the  end  of 
the  group,  and  a  repeating  field  in  the  middle  to  display 
previously  entered  data. 
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Placing  the  cursor  on  a  field  and  pressing  an  action  key, 
<PF>  key,  allows  you  to  modify  the  field  by  invoking  a  more 
detailed  screen  for  the  selected  action.  The  content  of  the 
bottom  field  is  not  part  of  the  specification  and  cannot  be 
edited.  Pressing  <ENTER>  adds  the  contents  of  the  new  data 
field  to  the  group.  Fields  can  be  deleted  by  moving  the  cursor 
to  the  desired  field  and  pressing  <DELETE>  (PF??). 

Syntax  checking  is  provided  for  each  specification  screen 
in  order  to  shorten  the  amount  of  time  needed  to  create  a  valid 
LEX  program. 

7 . 4 . 1 . 1  State  Definition 

The  State  Definition  function  is  used  to  list  and  define 
states  which  are  used  in  pattern/state  and  action  definitions. 
States  are  used  to  signify  that: 

1. )  a  certain  event  has  occurred 

2. )  specifications  can  be  created  which  allow  only 

certain  actions  to  occur  in  certain  states 

For  example,  when  a  text  SECTION  <number>  is  recognized,  the 
state  SECTION  will  be  set  to  an  "on".  A  specification  could 
then  be  defined  which  would  recognize  Section  Titles  (defired  by 
<center><underl ine>  formatting  codes)  only  when  the  state 
SECTION  was  set  on. 


States  are  identifiers  and  may  appear  in 
state  is  used  in  the  pattern/state  and  action 
without  being  defined  in  the  State  Definition 
issued.  A  comment  field  is  provided  for  each 
the  State  Definition  form. 


any  order.  If  a 
definitions 
Form,  a  warning  is 
state  entered  in 
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Select  <ENTER>  This  action  will  pass  the  user  into  the  a 

second  form. 
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Figure  7-4  State  Definition  Screen  -  Other  Options 


Insert/Update  <ENTER>  This  action  will  insert  new  data  or 

update  existing  data  in  the  state 
definition. 

Delete  <PF12>  This  action  will  delete  the  state 

definition  listed. 

7. 4. 1.2  Character  Class  Definition 

The  Character  Class  Definition  form  is  used  to  list  and 
define  character  class  names  and  their  regular  expression 
definitions.  The  character  class  name  serves  as  a  mnemonic  for 
the  word  processing  formatting  code.  These  class  names  are 
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used  in  the  pattern  definitions  in  place  of  a  regular 
expression.  All  character  class  names  must  be  defined  in  this 
form  befor  they  are  used  in  a  pattern.  If  the  character  class 
is  not  defined  in  this  form,  a  warning  will  be  issued. 


Figure  7-5  Character  Class  Definition  -  Select 
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Figure  7-6  Character  Class  Definition  -  Other  Options 


7. 4. 1.3  Pattern/ Act ion/state  Definition 

The  Pattern/Action/State  Definition  function  is  used  to 
list  patterns  and  actions.  The  syntax  of  patterns  is  provided 
in  the  next  section.  An  action  is  any  valid  C  statement  that 
normally  occurs  in  the  body  of  a  procedure.  The  special  C 
action  "ECHO;"  causes  the  contents  of  the  input  buffer  to  be 
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output  without  formatting  information.  The  special  C  action 
"BEGIN  state_name;"  sets  the  current  state  to  the  specified 
state  name.  The  current  state  name  is  reset  if  the  state  name 
is  "0". 
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IISS  SGML  Auto  Tagging  Facility 
Pattern/Actlon/State  Definition 


<enter>  -  Insert/Update/Select  (Action  or  State) 
<p£12>  -  Delete 


7. 4. 1.4  C  Declarations 


UM  620344900 
30  September  1990 


This  C  definition  form  is  used  to  insert  C  statements  for 
the  LEX  module  yylex,  this  module  name  is  a  unique  name  to  the 
Lexical  Writer  and  should  not  be  changed.  C  statements  are  used 
to  define  variables  referenced  in  actions  and  to  perform 
initialization  of  the  output  document  file.  For  example,  you 
might  wish  to  output  several  tags  before  beginning  the  Tagger 
processing  of  your  word  processing  file. 


Figure  7-10  C  Declarations  Section 


7.4. 1.4.1  Pattern  Specification  Syntax 


Patterns  represent  elements  of  a  document  that  are  to  be 
tagged.  These  patterns  consist  of  strings  and  operators.  A 
string  is  a  sequence  of  printable  characters.  An  operator  is 
one  of  the  following  characters; 


"\[]'-?.*+|  ()$/{)%<> 


The  characters  <space>,  <>  (angle  brackets),  ‘  (karat),  % 
(percent) ,  and  $  (dollar  sign)  are  special  reserved  characters 
to  LEX  and  should  be  enclosed  in  double  quotes  or  preceded  by  a 
backslash.  Warnings  will  be  issued  for  improper  use  of  these 
characters . 
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7 . 4 . 1 . 5  Save  Auto  Tag  Definition  File 

The  Save  Auto  Tag  Definition  File  function  is  used  to  save 
the  defined  Autotag  data.  The  selection  of  this  function  v.'ill 
return  you  to  the  previous  screen  form. 

7.4.2  The  Lexical  Writer 

The  Lexical  Writer  of  the  EDS  uses  the  specification 
defined  in  the  Autotag  utility.  The  Lexical  Writer  is  not 
accessed  in  the  IISS.  This  component  is  invoked  on  the  command 
line,  i.e.  a  '$'  prompt: 

LEX  specif icationname. L  <RETURN> 

This  component  of  the  EDS  Tagger  will  create  a  C  program, 
LEXxx.C.  The  C  program  name  is  specified  by  the  system;  the 
nam.e  LEXxx.C  is  the  actual  name  assigned  that  C  program. 

7.4.3  Run-Time  Processor 


You  nov;  have  a  C  program  from  the  Lexical  VN’riter.  This 
program  must  now  be  com.piled  and  linked.  The  command: 

CC  LEXxx  <RETURN> 

will  compile  the  application  and  create  and  object  file, 
LEXxx. OBJ. 


The  application  must  now  be  linked.  The  command: 
LINK  LEXxx, [dxtag]dstag/i=(DX, DXPRE)  <RETURN> 


will  link  the  application.  The  directory  [dxtag]  and  library 
dxtag  contain  the  runtime  support  modules  for  DECDX  document 
taggers . 


The  application  is  ready  to  run  to  tag  a  docum.ent  in  SGML. 
Phis  application  '.vill  take  the  word  processor  file  name  that  you 
supply  and  tag  it.  The  C  program  LEXxx  will  write  the  nev;ly 
tagged  file  into  the  file  name  that  you  specify.  The 
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following  is  the  command  to  enter  to  begin  the  application. 

RUN  LEXxx  <RETURN> 

Two  input  fields  will  appear  on  the  screen.  They  are: 

file? 

out? 

you  must  enter  the  word  processor  filename  in  the  file  input 
field.  The  input  for  the  out  field  is  a  filename  for  the  SGML, 
tagged  document,  so  whatever  name  you  input  here  will  become  the 
newly  tagged  and  parsed  SGML  document  file  name. 

The  application  is  built  for  the  specification  defined  in 
Autotag.  The  Run-time  application  tags  the  document  and  parses 
it  also.  The  former  word  processor  document  is  now  an  SGML 
tagged  document  for  your  u.-2. 
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SECTION  8 
GRAPHICS  SUPPORT 


8 . 1  EDS  and  Graphics 

EDS  is  used  to  combine  text  and  graphics  into  a  single, 
cohesive,  integrated  document.  This  eliminates  the  need  for 
manually  "cutting  and  pasting"  the  graphics  into  the  text. 

There  are  several  externally  generated  graphics  that  can  be 
included  in  an  EDS  document.  You  can  use  IISS  screen  dumps,  you 
can  use  Apple  Macintosh  MacPaint  files,  you  can  use  SDRC  I-DEAS 
files,  and  other  formatted  (human  readable)  Postcript  files  for 
inclusion  in  an  EDS  document. 

8 . 2  IISS  Screen  Dumps 

The  EDS  was  developed  to  assist  the  user  in  conforming  to 
documentation  standards  and  to  integrate  text  and  graphics.  EDS 
is  automatically  capable  of  using  certain  keyboard  character 
seguences  to  capture  IISS  screen  dumps.  There  is  a  character 
sequence  which  can  be  used  for  capturing  these  IISS  screens, 
<CTRL  p>. 

The  <CTRL  p>  character  sequence  captures  IISS  screen  dumps 
in  either  the  Postscript  format  or  the  ASCII  file  format.  The 
EDS  has  certain  links  defined  for  it.  The  link  for  your  account 
and/or  your  application  may  be  defined  for  the  Postscript  form.at 
or  the  ASCII  format.  You  must  be  correctly  linked  to  the 
PSPRIHT  routine  from  DEVDRV  in  order  to  produce  the  Postscript 
pictures  from  the  IISS  screens.  Please  note  that  you  may  be 
able  to  save  these  IISS  screens  but,  in  order  to  print  them 
there  must  be  a  printer  that  supports  Postscript  available  to 
you . 

8 . 3  Apple  Macintosh  MacPaint  Files 

The  generation  of  Apple  MacPaint  graphics  for  the  general 
computer  user  has  been  v/idespread  in  the  industry.  However,  as 
v;ith  most  of  these  independent  systems  there  has  been  no  easy 
v.'ay  to  include  these  graphics  into  documents.  The  EDS  was 
developed  to  include  externally  generated  graphics  into  the  EDS 
document.  The  Macintosh  MacPaint  files  are  converted  to  a 
language  that  the  EDS  can  process,  this  language  is  Postscript. 
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The  content  of  and  the  format  of  the  converted  file  is  based  on 
the  EPSF  structure  conventions  documented  by  Adobe  Systems, 
Incorporated.  This  convention  is  available  from  Adobe  Systems, 
Incorporated  and  Structural  Dynamics  Research  Corporation. 

An  EDS  application  program,  the  MPEPSF  translator,  is 
available  for  the  Apple  Macintosh  that  translates  and  converts 
MacPaint  files  to  an  encapsulated  Postcript  file  (EPSF) .  This 
application  must  be  executed  on  the  Apple  Macintosh.  The 
translation  of  the  MacPaint  files  is  not  dependent  on  the  IISS 
nor  on  any  additional  EDS  components. 

This  EPSF  file  is  an  ASCII  text  file  containing  Postscript 
language  statements  that  describe  the  MacPaint  file.  EPSF 
files  can  be  transferred  to  the  VAX  via  a  communication  package 
and  then  used  in  an  EDS  document. 

8.3.1  MacPaint  File 

The  icon  driven  software  available  on  the  Apple  Macintosh 
is  used  by  the  user  to  create  and  save  a  MacPaint  file.  The 
conversion  program  is  selected  from  the  Macintosh  menu. 

8.3.2  MPEPSF 

Now  that  you  are  in  the  MPEPSF  application,  you  can  convert 
a  MacPaint  file.  The  MacPaint  document  can  be  viewed  by 
selecting  the  OPEN  menu  item  from  the  FILE  function.  The  name 
of  the  MacPaint  file  must  be  selected  for  any  processing  to 
continue . 

Conversion  of  the  MacPaint  file  is  begun  by  selecting  the 
CONVERT  item  from  the  FILE  function.  An  output  file  name  must 
be  supplied  by  you  before  the  file  is  converted.  After  the  file 
is  converted,  exit  from  the  MPEPSF  application  by  selecting  the 
QUIT  item  from  the  FILE  menu. 

8.3.3  File  Transfer 


The  converted  file  must  be  sent  to  the  VAX.  Any  file 
transfer  program  that  is  available  to  you  should  work  for  this 
file  trasfer,  i.e.  Kermit,  Apple  MacTerminal,  Red  Ryder.  The 
converted  and  transferred  file  is  ready  for  printing  to  any 
Postscript  compatible  print  device. 
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8.3.4  Print 


The  use  of  these  files  in  an  EDS  document  requires  an 
include  statement  in  the  document  source.  The  syntax  for  this 
is  contained  in  the  figure  markup  statements  for  the  figure: 

<f igure> 

^graphic  file  =  " filename . epsf"  place-" f ixed" 
</graphic> 


</f igure> 

See  Appendix  C  for  an  example  of  a  marked  up  EDS  source 
document . 

These  files  require  the  following  print  qualifiers  for  the 
VAX  when  printing  as  an  individual  graphic  and  not  in  an  EDS 
document : 


/NOHEAD 

/NOTRAIL 

/NOFLAG 

/NOBURST 
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SECTION  9 
EDS  FORMATTER 


9 . 1  Formatting  the  EDS  Document 

The  EDS  Formatter  reads  an  SGML  tagged  document,  one 
successfully  run  through  the  SGML  Parser,  and  uses  the 
formatting  information  contained  in  the  Document  Profile  to 
determine  the  layout  or  format  style  of  the  document.  Formatter 
output  is  in  the  form  of  Postscript  language  statements.  These 
statements,  when  recognized  by  a  Postscript  output  device,  will 
format  the  document  as  defined  in  the  DTD,  the  Document  Profile, 
and  the  SGML  Parser.  These  Postscript  commands  are  printed  and, 
also,  stored  in  a  file.  The  EDS  Formatter  also  inserts  the 
graphics  into  the  formatted  text. 

9.2  EDSFMT 

This  is  the  program  module  of  the  EDS  that  formats  the 
document.  The  user  must  log  into  the  IISS  with  a  valid  user  id 
and  account.  The  IISS  Function  Screen  will  appear  on  the  screen 
after  successful  logon.  Place  the  cursor  on  the  Function  field, 
enter  EDSFMT,  and  press  <ENTER>.  The  EDS  Document  Formatter 
Screen  will  appear  next.  The  Document  Formatter  Screen  is  forms 
based  and  has  input  fields  for  the  input  filename,  the  Document 
Profile,  and  the  output  filename. 
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Figure  9-1  Document  Formatter  Screen 
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The  input  fields  on  the  screen  are  Document  Name,  Document 
Pi'oiile,  and  Output  File. 


Document  Name: 


Do  ument  Profile: 


Out  ;!Ut  i'ile : 


This  is  the  name  of  the  Parsed  file, 
reference  Section  6,  not  the  the  name  of 
the  document  text  file. 

This  is  the  name  of  the  Document  Profile 
to  use  for  the  formatting  requirements 
on  this  document. 

This  is  the  name  of  the  generated  output 
file  from  the  formatter  process,  i.e. 
f i lename . out . 


Thoc.e  input  fields  must  be  entered  in  order  to  successfully 
format  a  document.  An  incorrect  filename  or  Document  Profile 
nano  will  return  an  error  message  to  the  screen.  You  will  then 
no.'  1  to  re-enter  the  necessary  input.  The  <ENTER>  key  will 
cumplete  the  form  and  begin  the  format  process. 

After  the  document  has  been  formatted  another  form  will 
appear.  This  form  will  ask  you  if  you  want  to  print  the  output. 
Tt;  ■  deiault  assignment  lor  this  message  is  'YES',  a  press  of  the 
<■  i;:  .  key  will  send  the  formatted  document  to  a  print  device. 

A  ':,3'  response  will  bring  you  back  to  the  previous  form  and  the 
QP  :  key  cPF4'-  will  also  bring  you  back  to  the  previous  form, 
th-e  Document  formatter  Screen. 

You  have  nov;  successfully  formatted  a  document.  Your 
doewnent  includes  externally  generated  graphics. 
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APPENDIX  A 


EDS  DTDBLD  Document  Type  Definition 

The  following  pages  are  computer  listings  of  a  document 
definition . 
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DEnO.DTO  •-  OocuBent  Type  Definition  for  Deso  Docunents 

This  Document  Type  Definition  should  be  used  for  all  I  CAM 
docunents  written  by  lISS  coalition  itesbers.  Please  do  not 
•ake  any  changes  to  this  docuaent. 

Crested  ;  1 S-Novenbe r - 1 98 7  Steve  Parker 
Revised  :  IS-November-l 987  Steve  B  .«er 


rlDOCTYPE  deaodoc  I 


<!--  Define  a  list 

of  entity  refs  that  can  be  used  for  long  string  n 

< ! ENTITY 

AOL 

'Application  Definition  Language’  > 

< ! ENTITY 

AI 

'Application  Interface’  > 

< • ENTITY 

AP 

'Application  Process"  > 

<  ENTITY 

CDC 

'Control  Data  Corpora*- i rr.“  > 

< ! ENTITY 

CM 

'Configuration  Management'  > 

< ! ENTITY 

CDh 

'Common  Data  Model'  > 

< ! ENTITY 

DM 

'Documentation  Management'  > 

< 1  ENTITY 

DS 

'Development  Specification'  > 

< ! ENTITY 

EDS 

'Electronic  Documentation  System'  > 

< ! ENTITY 

PD 

'Form  Definition’  > 

< lENTITY 

PDEE 

'Forms  Driven  Form  Editor’  > 

< ! ENTITY 

FDL 

'Forms  Definition  Language’  > 

< ! ENTITY 

rz 

'Form  Editor"  > 

< 1  ENTITY 

ELAN 

"Forms  Language  Compiler"  > 

<  :  ENTITY 

FP 

"Form  Processor"  > 

< ! ENTITY 

IISS 

'Integrated  Information  Support  System"  > 

< ; ENTITY 

ISO 

'International  Standards  Orignization"  > 

< ; ENTITY 

LOS 

"Layout  Optimization  System"  > 

< lENTITY 

NDDL 

'Nuettal  Data  Definition  Language’  > 

< ! ENTITY 

NDML 

'Nuetral  Data  Manipulation  Language'  > 

< ! ENTITY 

NTN 

'Network  Transaction  Manager'  > 

< ! ENTITY 

OS 

"Operating  System"  > 

< lENTITY 

PS 

"Product  Specification*  > 

< 1  ENTITY 

SDRC 

"Structural  Dynamics  Research  Corporation 

< 1  ENTITY 

SGhL 

'Standard  Generalized  Markup  Language'  > 

< 1  ENTITY 

TOC 

"Table  of  Contents'  > 

< lENTITY 

UI 

"User  Interface"  > 

< ! ENTITY 

uins 

'User  Interface  Management  System"  > 

< 1  ENTITY 

UIS 

"User  Interface  Services"  > 

< lENTITY 

DTP 

'unit  Test  Plan’  > 

< 1  ENTITY 

VT 

"Virtual  Terminal’  > 

<I —  Define  Document 

Markup 

>  for  a  DEMO  Document 

—  > 

< I  ELEMENT 

demodoc 

0 

o 

(body)  > 

< ; ELEMENT 

body 

- 

- 

(hdl,  (paraO  |  paral 

1  para2  )  para3  I 

1  pa 

< ! ELEMENT 

hdl 

- 

o 

( 1  PCDATA) 

> 

< 1  ELEMENT 

paraO 

- 

o 

( 1  PCDATA) 

> 

<! ELEMENT 

paral 

- 

o 

(« PCDATA) 

> 

< 1  ELEMENT 

para2 

- 

o 

(I PCDATA) 

> 

<! ELEMENT 

para3 

- 

o 

( 1  PCDATA) 

> 

<1  ELEMENT 

para4 

- 

0 

(1  PCDATA) 

> 

<! ELEMENT 

figure 

- 

- 

( ( f igbody 

1  graphic  1 

i  report)  ,  f igdese?) 

<1  ELEMENT 

f igdese 

- 

- 

( f ioref 7, 

fi9nuB7p  > 

t ! ELEMENT 

f Igref 

- 

o 

(•PCDATA) 

> 

< 1  ELEMENT 

f  ignuii 

- 

o 

(•PCDATA) 

> 

' • FI FMENT 

f igtitle 

• 

o 

(•PCDATA) 

> 

< I FLCMCNT 

list 

- 

- 

(item)* 

> 

figure 
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<!ELCnENT  ittn 
<! ELEMENT  report 
<!ELCnEN7  graphic 
< I  ELEMENT  figbody 

<: —  Define  Attributes 

<!ATTL1ST  graphic 


> 

< ! ATTLIS7  report 


1> 


O  (I  PCDATA)  > 
(* PCDATA)  > 
(* PCDATA)  > 
-  (« PCDATA)  > 


—  > 


ile 

CDATA 

•  REO’JIRED 

f  nt 

(epsf  1  ipic) 

"epsf “ 

place 

(fixed  1  float) 

"float" 

posx 

(left  1  center  | 

right) 

"center " 

posy 

(top  1  Biddle  1 

bottom  1  any) 

"middle " 

width 

NMTOKENS 

"6 .5IN" 

depth 

NKTOKE’JS 

"5.SJI." 

border 

NMTOKENS 

"r.’ONE" 

shadow 

NMTOKENS 

file 

CDATA 

IREOUIRED 

f  i;t 

( text ) 

“text"  > 
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APPENDIX  B 


EDS  Unit  Test  Plan  Parsed  Document 

The  following  pages  are  computer  listings  of  an  EDS  unit  test 
plan  manual  that  has  been  parsed. 
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ICAHUTPl 
rHONTJ 
COVPG ) 

SYSTTL) 

TTLl INTEGRATED  INrORKATlON  SUPPORT  SYSTCn  (XISS) 

/TTL) 

/SYSTTL J 
DOCTTL) 

TTLIUSER  INTERrACt/VIRTUAL  TERMINAL  INTERFACE  (OX/VTI) 
/TTLl 

TTL) COMPUTER  PROGRAM  UNXT  TEST  PLAN 
/TTL) 

TTLICONFIGURATION  ITEM:  EDS  SGML  PAfCtr 

/TTLl 

/DOCTTL 1 

D0CDATE131  March  1966 

/DOCDATE 1 

RECBLK) 

RECTTL IPREPARED  FOR: 

/RECTTL) 

ALINE  1  SYSTRAN  CORPORATION 
/ALINE) 

ALINE14126  LINDEN  AVE . 

/ALINE) 

ALINE IDAYTON,  OHIO  45432-3068 
/ALINE) 

/RECBLK  1 
SNDBLK ) 

SNDTTL IPREPARED  BY: 

/SNDTTL) 

ALINE) STRUCTURAL  DYNAMICS  RESEARCH  CORPORATION 
/ALINE) 

ALINE  12000  EASTMAN  DRIVE 
/ALINE) 

ALINE IMILFORD,  OHIO  45150 
/ALINE) 

/SNDBLK ) 

/COVPG ) 

CONTENTS) 

TTL) TABLE  OF  CONTENTS 
/TTL) 

TTl2 IPage 
/TTL21 

XSECTNO)SECT10N  1.0 
/XSECTNO) 

XSECTNMlGENERAL  . . . 

/XSECTNM) 

PONO)l-l 
/PGNO 1 
XCHAPNOll.l 
/XCHAPNO) 

XCHAPNM)  Purpoat  . 

/XCHAPNM) 

PCNO)l-l 

1/PGNO) 

[XCHAPNO)! .2 
i/XCHAPNO) 

IXCHAPNM)  Projtct  Ratcrancaa  . . 

[/XCHAPNM) 

[PGNO)l-l 
I /PGNO) 

[XCHAPNO] 1.3 
[/XCHAPNO) 

IXCHAPNM]  Tarai  and  Abbravlatlons  . 

I  /XCMAPNM] 
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PCNon-2 

/PGNO) 

XSECTNO I  SECTION  2.0 
/XSECTNO) 

XSECTNHIDEVELOMENT  ACTIVITY  . 

/XSECTNBl 

PGN012-1 

/PGNO) 

XCHAPNO]2.1 

/XCHAPNO) 

XCHAPNni  StattMvnt  ot  Prtttst  Activity 
/XCHAPNM) 

PGN0)2-1 
/PGNO 1 
XCHAPNO)2 .2 
/XCHAPNO) 

XCHAPNK]  Pretext  Activity  Pesultc  _ 

/XCHAPNK) 

PGNO)2-l 

/PGNO) 

XSECTNO)SECTION  3.0 
/XSECTNO) 

XSECTNr.)  SYSTEM  DESCRIPTION  . 

/XSECTNM) 

PGNO)3-l 

/PGNO) 

XCHAPNO) 3.1 
/XCHAPNO) 

XCHAPNM)  Systeir.  Deicription  . 

/XCHAPNM) 

PGNO]3-l 

/PGNO) 

XCHAPNO) 3. 2 
/XCHAPNO) 

XCHAPNK)  Texting  Schedule  . 

/XCHAPNM  J 
PGNO) 3-1 
/PGNO) 

XCHAPNO] 3. 3 
/XCHAPNO) 

XCHAPNM]  Pirxt  Lo&xtion  Texting  . 

/XCHAPNM) 

PGNO) 3-1 
/PGNO) 

XCHAPNO) 3. 4 
/XCHAPNO) 

XCHAPNM]  Subxequent  Loextion  Texting  . 
/XCHAPNM) 

PGNO] 3-2 
/PGNO) 

XSECTN0]SECT10N  4.0 
/XSECTNO] 

XSECTNMjSPECiriCATlONS  AND  EVALUATIONS 
/XSECTNM) 

PGNO) 4-1 
/PGNO) 

XCHAPNO] 4.1 
/XCHAPNO) 

XCHAPNM)  Text  Sped f icxtlonx  . 

/XCHAPNM] 

PGNO] 4-1 
/PGNO) 

XCHAPNO) 4. 2 
/XCHAPNO) 

xCKAFNn)  Text  Methods  and  Conatraintx 
/XCHAPNM) 
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FGN014-1 

/PGNO) 

XCHAPNOJ4 . 3 
/XCHAPNOl 

XCHAPNM)  Test  Progression  . 

/XCHAPNK) 

PGNO 14-2 
/PGNO! 

XCHAPNOl 4 . 3 
/XCHAPNO) 

XCHAPNKl  Test  Evaluation  . * . 

/XCHAPNM ! 

PGNO I  4-2 
/PGNO] 

XSECTNOISICTION  5.0 
/XSECTNOl 

XSECTNP.  ITEST  PROCEDURES  . 

/XSECTNM ) 

PGNO)5-l 

/PGNO] 

XCHAPNOl 5.1 
/XCHAPNOl 

XCHAPNMl  Test  Description  . 

/XCHAPNP.  1 

PGN015-1 

/PGNO] 

XCHAPNO 15. 2 
/XCHAPNOl 

XCHAPNKl  Test  Control  . 

/XCHAPNM 1 
PGNO 15-1 
/PGNOl 
XCHAPNO  15. 3 
/XCHAPNO] 

XCHAPNP.  1  Test  Procedures  . 

/XCHAPNP) 

PGN0)5-1 

/PGNO) 

LISTAPPX) 

TTLlAppendices 

/TTLl 

XAPPNOlA-1 

/XAPPNO] 

XAPPNPlvalid  SGPL  Validation  Suite  Test  Docuaents  .. 
/XAPPNPl 
i  PGNOl A- 1 
:/PGN01 
XAPPNO]B-l 
/XAPPNO) 

XAPPNPIinvalid  SGML  Validation  Suite  Test  Docuaents 
i/XAPPNH) 

:PGN0)B-1 

1/PGNO) 

I /LISTAPPX) 

! /CONTENTS) 

1/PRONTJ 
I  BODY) 

[SECT) 

[SECTNOISECTION  1 
1/SECTNO) 

[SECTNn) GENERAL 

i/SECTNH) 

iCKAP) 

ICllAPNOll.l 
1  /CHAPNO) 

I  CMArNP jPurpose 
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/CHAPNM  j 

PClThii  Unit  Test  Plan  (UTP)  •ctabliahea  th«  aethodoloqy  and  procadurea 
jted  to  adequately  test  the  capabilities  of  the  computer  program  identified 
IS  the  SGML  Paiser.  The  SCHL  Parser  is  one  configuration  item  of  the 
Integrated  Information  Support  System  (IISS)  Electronic  Documentation  System  (ED 
l/PP  I 
1/CHAPl 
I  CHAP ) 

ICHAPNOJl .2 
i/CHAPNOl 

( CHAPNH 1  Project  References 

I /CHAPNM 1 

UIST) 

[Il)\ll)  Systran, 

|UL)ICAH  Documentation  Standards 
(/ULI, 

1D5150120000C,  S  September  1963. 

|yin 

Ill]\i2]  International  Organisation  for  Standardization, 

1 UL 1 1 nf orma t ion  Processing  -  Text  and  Office  Systems  - 
Standard  Generalized  Harkup  Language  (SCnL) 
l/uL) ,  ISO  eeis, 

15  October  1966. 
l/Il  1 

|1I1\|31  International  Organization  for  Standardization, 

(UL)Off ice 

Document  Ar ch i tec tu re/Cf f i ce  Document  Interchange 
Format 

l/UL),  ISO/DP  8613/1-6,  October  1985  (Draft). 

1/111 

llli\(41  American  National  Standards  Institute, 

( OL 1  Arne  r 1  can 

National  Standard  for  Information  Systems  -  Computet 
Graphics  -  Metafile  for  the  Storage  and  Transfer  of 
Picture  Description  Information 
l/ULl ,  ANSI  X/3. 122-1986, 

August  21,  1986. 

I/Il  ) 

|I1]\|5|  Structural  Dynamics  Research  Corporation, 

( UL  1  Form 

Processor  User's  naoual 

l/UL),  UP.  620244200A,  16  February  1987. 

i/n ) 

[ll)\16]  Structural  Dynamics  Research  Corporation, 
lULlVi rtual 

Terminal  Operator  Guide 

I/UL),  OP  620244000A,  16  February  1987. 

I/Il  ) 

in)\17)  B.E.  Leak, 

(ULILEX  -  Lexical  Analyzer  Generator,  IS 
Workbench  for  VAX/VHS  Ptogramaera  Guide 

l/UL) . 
t/Il  I 

[ll]\(6|  Structural  Dynamics  Research  Corporation, 

( UL 1  Form 

Processor  Development  Specification 
l/Ul),  DS  620244700A,  16  February  1987 

l/ni 

I /LIST) 

I /CHAP) 

I  CHAP] 

I CHAPNO)!  . 3 
l/CHAPNO) 

I CMAPNP iTcras  and  Abbreviations 
1 /CHAPNP) 

I  LIST  I 
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1121 

lULlAaerican  Standard  Coda  for  Xnforaatien  Interchange  (ASCII) 

I /UL ) ; 

The  character  aet  defined  by  ANSI  a3.4  and  uaed  by  Moit  coaputer 
vendor  r  . 

1/12) 

11) 

|UL)At  ibute 

l/UL):  A  characteristic  used  to  qualify  an  cleaent 
within  a  document. 

I/I2) 

1121 

[ UL I  Character  Set 

i/UL):  A  mapping  of  a  character  repertoire  onto  a 

code  set  such  that  each  character  is  associated  with  its  coded 

representation. 

1/12) 

1121 

I UL 1  Compound  Document 

!/ULi:  A  document  which  may  contain  mixed 

content  (text,  graphics,  etc.'). 

1/121 

1121 

lULlComputer  Graphics  netafile  (COM) 
l/ULl:  A  standard  file  format 

for  the  storage  and  retrieval  of  pi 'tore  description 
information. 

[/I2  1 
1121 

(ULlCotr.puter  Program  Configuration  Item  (CPCl) 
i/ULl:  An  aggregation 

of  computer  programs  or  any  of  their  discrete  portions,  which 
satisfies  an  end-use  function. 

I/I21 

(121 

lULlCohforming  SGKL  Application 
i/ULl:  An  SGKL  application  that 

requires  documents  to  be  conforming  SGHL  documents,  and  whose 
documentation  meets  the  requirements  of  this  International 
Standard. 

1/121 

(121 

( UL 1 Context-Ci reeled  Editor 

j/ULl;  An  EDS  application  which  guides 

the  user  through  the  process  of  document  creation  and  revision 
by  using  the  document  type  definition  as  a  model  for  which 
logical  elements  may  be  included  in  the  document, 

1/121 

(121 

[ULlDcscriptive  Markup 

I/ULl:  Information  added  to  a  document  that 

enables  an  application  program  to  process  the  document. 

(/121 

(121 

(ULlDocument  Type  Definition  (DTD) 
j/ULl:  Pules  determined  by  an 

application  that  apply  SGML  to  the  markup  of  documents  of  a 
particular  type.  A  document  type  definition  includes  a  formal 
specification,  expressed  in  a  document  type  declaration,  of  the 
element  types,  element  relationships  and  attributes,  and 
references  that  can  be  represented  by  markup.  It  thereby 
defines  the  vocabulary  of  the  markup  for  which  ICHL  definea  the 
syntax.  A  DTD  can  also  include  comments  that  describe  the 
semantics  of  elements  and  attributes,  and  any  application 
conventions. 

1/I2I 
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1121 

I UL  I  cl *c t r oni c  PocuBcntation  Syatas  (CDt) 
lAll-I:  An  intc9r*tcd  act 

of  aoftware  tools  and  application  prograns  w^ich  operate  upon  a 
doeuxent  through  various  stages  of  a  document  life  cycle 
consisting  of  editing  (creating/revising),  formatting,  imaging, 
storage,  and  transfering. 

1/12) 

1121 

I UL ) Element 

l/UL):  A  component  of  the  hierarchical  structure  defined 
by  a  document  type  definition;  it  is  identified  in  a  document 
instance  by  descriptive  markup,  usually  a  start-tag  and  end-tag. 
t/12) 

(12) 

(ULlElement  Declaration 

l/UL):  A  markup  declaration  that  contains 

the  formal  specification  of  the  part  of  an  element  type 
definition  that  deals  with  the  content  and  markup  minimisation. 
(/I2  ) 

(12) 

lULlCntity 

i/ULl;  A  collection  of  characters  that  can  be  referenced 
as  a  unit. 

1/121 

112) 

(ULlCntity  Declaration 

l/UL):  A  markup  declaration  that  assigns  an  SSKL  name 

to  an  entity  so  that  it  can  be  referenced. 

1/121 

(12) 

(UL)Entity  Reference 

(/UL):  A  reference  that  is  replaced  by  an  entity. 

(/I2) 

(12) 

(ULirield 

(/UL);  Two-dimensional  apace  on  a  terminal  screen. 

1/12) 

(12) 

(ULlCorm 

i /UL ) :  A  Structured,  view  which  may  be  imposed  on  windows  or 
other  forms.  A  form  is  composed  of  fields.  These  fields  may  be 
defined  as  forms,  items,  or  windows. 

1/12) 

(12) 

(ULlform  Definition  (FD) 

(/UL):  Form  definition  Language  after 

compilation.  It  is  read  at  run-time  by  the  Form  Processor. 

1/121 

(121 

(ULlForm  Definition  Language  (FDD 
l/UL):  The  language  in  which 

electronic  forms  are  defined. 

1/121 

(12) 

(ULjForm  Editor  (FE) 

j/UL):  A  subset  of  the  IISS  User  Interfsce  that 

is  used  to  create  definitions  of  forms.  The  FE  consists  of  the 

Forms  Driven  Form  editor  and  the  Forms  Language  Compiler. 

1/121 

(121 

(ULlForm  Hierarchy 

i/ULl:  A  graphic  representation  of  the  way  in 

which  forms,  items,  and  windows  are  related  to  their  parent 

form. 

1/121 
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112! 

lULlrorpi  Language  Conpiler  (FLAN) 

I /UL ) :  A  aubaet  of  the  FE  that 

consiKtt  of  a  batch  proceat  that  acceptt  a  aeries  of  fom 
definition  language  atatenents  and  produces  fo'B  definition 
files  aa  output. 

1/12) 

112) 

lULlForn  Processor  (FP) 

l/UL):  A  subset  of  the  llSS  User  Interface 

that  consists  of  a  set  of  callable  execution-tiaie  routines 

available  to  an  application  progcaD  for  fors  processing. 

1/12) 

(12) 

lULlForms  Driven  Form  Editor  (FOFE) 
l/T-’L);  A  subset  of  the  FE  which 

consists  of  a  forns-driven  application  used  to  create  Forn 
Definition  files  interactively. 

1/121 

112) 

(ULlGenerir  Identifier 

l/UL):  A  naire  that  identifies  the  elenent  type  of  an 
clement . 

1/12) 

(12) 

lULlGI 

l/UL):  Generic  Identifier. 

1/12) 

112) 

lULinss  Function  Screen 

l/UL):  The  first  screen  that  is  displayed 

after  logon.  It  allows  the  user  to  specify  the  function  to 
access  and  the  device  type  and  device  name  on  which  to  work. 
1/12) 

112) 

(UL) Integrated  inforaation  Support  Systea  (lISS) 
l/UL) :  A  test 

computing  environment  used  to  investigate,  dcB  nstratc,  and  test 
the  concepts  of  information  aanagement  and  inforaation 
integration  in  the  context  of  Aerospace  Manufacturing.  The  ItSS 
addresses  the  problems  of  integration  of  data  resident  on 
heterogeneous  data  bases  supported  by  heterogeneous  coaputers 
interconnected  via  a  Local  Area  Network. 

1/12) 

112) 

lUDItem 

l/UL):  A  non-decomposable  area  of  a  fora  in  which 
hard-coded  descriptive  text  aay  be  placed  and  the  only  defined 
areas  where  user  data  aay  be  input/output. 

1/12) 

112) 

lULlLayout  Style 

I/UL):  The  specification  of  foraat  and  presentation 
for  logical  eleaents. 

!/I2) 

112] 

(ULILayout  Structure 

t/UL]:  The  hierarchy  of  all  layout  eleaents 
(pages,  fraaes,  blocks,  etc.)  for  a  docuaent. 

1/12) 

112) 

(ULlLogical  Structure 

(AIL):  The  hierarchy  of  all  logical  eleaents 
(paragraphs,  sections,  etc.)  within  a  docuaent. 

1/12) 

112) 
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|UL)n«rliup 

i/UL);  Text  that  it  added  to  the  data  ot  a  docuaent  in  order  to  convey 
inforaation  about  it. 

1/12) 

(I2I 

lULinariup  Riniaization 

(/UL):  A  feature  of  SGRL  that  allc>'v  aarkup  to  be 

ainiBized  by  ahortenin9  or  OBittin9  ta9t.  or  thortcnin9  entity  referencet. 
1/121 
112) 

|ULlHeita9C 

i/UL):  Deacriptive  text  which  aay  be  returned  in  Che 

atandard  acaaa9e  line  on  the  terainal  screen.  Heatagea  arc  used 
to  warn  of  errors  or  provide  other  user  inforaation. 

1/12) 

112) 

lULlnesaage  Line 

j/UL):  A  line  on  the  terainal  screen  that  is  used 

to  display  aessagea. 

1/12) 

1121 

lULlOperatlng  Syatea  (OS) 

t/UL):  Software  supplied  with  a  coaputer 

which  allows  it  to  supervise  its  own  operations  and  aanage 
aeceas  to  hardware  facilities  such  as  aeaory  and  peripherals. 

1/121 

112) 

lULlPage 

I/UL):  Instance  of  foraa  in  windows  that  are  created 

whenever  a  fora  is  added  to  a  window. 

1/12) 

1121 

lULlPaging  and  Scrolling 

I/UL);  A  aethod  which  allows  a  fora  to 

contain  aorc  data  than  can  be  displayed  at  one  tiae  with 
provisions  for  viewing  any  portion  of  the  data’buffer. 

1/12) 

112] 

I UL iParser 

I/UL):  An  application  prograa  that  deteraines  how  closely 
a  docuaent  conforas  .to  a  docuaent  type  definition  which  defines 
a  specific  docuaentation  standard. 

1/12) 

112) 

lULlPhysical  Device 

I/UL):  A  hardware  terainal. 

1/12) 

112) 

lULlPrevious  Cursor  Position 

I/UL);  The  position  of  the  cursor  when 

the  previous  edit  coaaand  was  issued. 

1/12) 

(12) 

lUDQualif ied  Naae 

I/UL);  The  naae  of  a  fora,  itea,  or  window 

preceded  by  the  hierarchy  path  so  that  it  is  uniquely 

identified. 

1/12) 

112) 

lULlStandard  Generalized  Markup  Language  (SCNL) 

I/UL] ;  A  language 

for  describing  docuaent  structures,  consisting  of  descriptive 
aarkup  which  is  added  to  a  docuaent  to  Indicate  where  logical 
eleaents  such  at  sections  and  paragraphs  begin  and  end. 

I/I2) 

112) 
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I UL ISubforn 

l/ULl;  A  form  that  is  used  within  another  forei. 

I/I2) 

112) 

tULlTag 

l/UL):  Descriptive  aarkup  indicating  the  start  or  end  of  a 

logical  elenent. 
l/12i 
112) 

1 UL I  Tagger 

( /UL ) :  An  application  program  which  provides  a  mschanism 
for  automatically  tagging  existing  documents  which  have  been 
created  by  word  processing  systems. 

1/121 

112) 

(ULlUser  Interface  (UI) 

l/UL):  IISS  subsystem  that  controls  the 

user's  terminal  and  interfaces  with  the  rest  of  the  system.  The 
UI  consists  of  two  major  subsystems:  The  User  Interface 
Development  System  (UIDS)  and  the  User  Interface  Management 
System,  (UIMS). 

1/12) 

112) 

(ULlUser  Interface  Management  System  (U1H5) 
l/UL):  The  run-time  UI . 

It  consists  of  the  Form.  Processor,  virtual  Terminal,  Application 
Interface,  the  User  Interface  Services,  and  the  Text  Editor. 
I/I21 
112) 

(ULlUser  Interface  Services  (UlS) 

(/UL):  A  subset  of  the  IISS  User 

Interface  that  consists  of  a  package  of  routines  that  aid  users 
in  controlling  their  environment.  It  includes  message 
management,  change  password,  and  application  definition 
services. 

(/121 

112) 

(ULlUser  Interfaee/Virtual  Terminal  Interface  (Ul/VTI) 

(/UL): 

Another  name  for  the  User  Interface. 

(/12) 

(12) 

(ULlVirtual  Terminal  iVT) 

i/UL):  A  subset  of  the  IISS  User  Interface 

that  performs  the  interfacing  between  different  terminals  and 
the  UI.  This  is  done  by  defining  a  specific  set  of  terminal 
features  and  protocols  which  must  be  supported  by  the  UI 
software  which  constitutes  the  virtual  terminal  definition. 
Specific  terminals  are  then  mapped  against  the  virtual  terminal 
software  by  specific  software  modules  written  for  each  type  of 
real  terminal  supported. 

(/1 2) 

112) 

(ULlVirtual  Terminal  Interface  (VTI ) 
l/UL):  The  callable  interface 
to  the  VT. 
t/12) 

112) 

lUDNindow 

l/UL):  Dynamic  ares  of  a  terminal  screen  on  which 
predefined  forms  may  be  placed  at  run-time. 

1/12) 

1121 

(I't  (Window  Manager 

I  'III  )•  A  feri’ity  which  allows  the  following  to 

te  man < pulatrd :  size  and  location  cf  windows,  the  device  on 
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which  an  application  ia  running,  the  pocltion  of  a  fora  within  a 
window.  It  ia  part  of  the  Fora  Proceaaot. 

1/12) 

I/LIST) 

I /CHAP) 

I /SECT) 

(SECT) 

[SECTNOISECTION  2 
l/SECTNO) 

ISECTNhlDEVELOPBENT  ACTIVITY 
l/SECTNM) 

1  CHAP ) 

1CHAPN0)2.1 

1/CHAPNO) 

[CKAPNr.lStateaent  of  Preteat  Activity 
l/CHAPNH) 

IPOlOuring  ayatent  development,  the  eonputcr  programs  were  teated 
progressively.  Functionality  was  incrementally  tested,  and  as  bugs  were 
discovered  by  this  testing,  the  software  was  corrected. 

I  PC  1 

(PCIThe  starting  point  for  the  development  of  the  EDS  SCHL  Parser  was  a 
Parser  implementation  for  the  HS-DOS  operating  system  developed  by  the  National 
Bureau  of  Standards  (NBS)  at  part  of  the  CALS  initiative.  For  EDS,  the  Parser 
was  ported  from  ns-DOS  to  the  operating  systems  supported  by  IISS.  As  the 
code  was  ported,  changes  were  made  to  eliminate  the  use  of  temporary  files, 
fix  minor  bugs,  and  add  additional  functionality  needed  to  support  EDS. 

I/PO) 

|PC]The  NBS  alto  developed  an  SGBL  Parser  validation  suite  consisting  of 
a  number  of  filet  that  test  specific  functionality  outlined  in  the  SCKL 
standard  (ISO  861$).  The  validation  suite  will  serve  as  the  basis  for 
the  EDS  SGHL  Parser  Unit  Test  Plan. 

I/PO) 

I /CHAP) 

( CHAP) 

|CHAPN0]2.2 

l/CHAPNO) 

1 CHAPNh )Pretest  Activity  Pesults 
( /CKAPNH) 

(PO)The  EDS  SGBL  Parser  successfully  pasted  the  NBS  validation  suite.  A  few 
minor  errors  were  found  in  the  validation  suite  filet  themselves  and  these 
were  corrected. 

1/PO) 

1/CHAP) 

I/SECT) 

I  SECT) 

( SECTNOISECTION  3 
l/SECTNO) 

ISECTNP.)  SYSTEM  DE5CBIPTION 
l/SECTNH) 

ICHAP) 

|CHAPN0)3.1 

l/CHAPNO) 

I CHAPNH ' System  Description 
I /CKAPNB) 

IP0)The  SGBL  Parser  is  the  component  of  the  Electronic  Documentation  System 
that  validates  the  logical  structure  of  a  document  against  a  previously  built 
SGBL  Document  Type  Definition.  It  insures  that  the  descriptive  mactup  in  the 
document  conforms  to  the  set  of  rules  defined  by  the  DTD.  The  DTD  determines 
what  generic  identifiers  arc  valid  at  any  point  in  the  document  and  hoy_sany 
times  they  may  occur. 

I/FO) 

|P0)ln  addition  to  validating  the  markup,  the  Parser  also  converts  the  document 
to  its  fully  narked  up  state  by  processing  all  Entity  references,  Attributes, 
and  expands  all  minimised  generic  identifiers  found  within  the  document. 

I/PO) 

I /CHAP) 
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[CHAP) 

(CHAPN013.2 

l/CHAPNC) 

( CHAPNH 1 Te s t 1 ng  Schedule 
I /CHAPNh 1 

jpCJSince  the  NBS  velldation  auite  i*  the  basic  for  the  Parser  test  v-lan, 
execution  of  this  unit  test  plan  is  not  dependent  upon  any  other  coaponents 
of  cither  COS  or  IlSS. 

I/PD) 

I /CHAP) 

I  CHAP  1 

(CHAPN0)3.3 

i/CHAPNO) 

I CHAPNh  Iri rst  Location  Testing 
[ /CHAPNh ) 

[PCIThese  tests  of  the  SChL  Parser  require  the  following: 
l/PO) 

(LIST) 

1 1 ' Equipment :  Air  Force  VAX,  terminals  supported  by  the  Virtual  Terminal 

I  /  ) 

I I 

1/1) 

[■)Support  Software:  C  run-time  libraries 
I /I  I 
1 1  ] 

I /I  i 

( 1  iPersonnel :  one  integrator  familiar  with  EDS 

1/1  ) 

I  1  1 
1/1  I 

niTraining:  the  CDS  User  Hanual  has  been  previously  delivered 

1/1  ) 

m 

l/l] 

I I  )Delivetables  ;  the  SGP.L  Parser  CPCI 

(/ll 

(1  ) 

1/n 

(llTest  Materials:  All  tests  are  run  using  the  NBS  SGML  validation 

suite  files 

l/l) 

(1) 
l/l  I 

|l)Security  Considerations:  None. 
l/l) 

HI 

l/l) 

I/LIST) 

I /CHAP) 

I  CHAP) 

iCKAPNO)3.4 

l/CHAPNO) 

( CHAPNK ) Subsequent  Location  Testing 
( /CHAPNH) 

(PCIThc  requirements  listed  above  must  be  met.  The  command  procedure 
PAPVAL.COn  can  be  run  to  execute  the  entire  NBS  SGML  validation  suite. 

The  output  file  PAPVAL.TST  can  then  be  compared  using  the  VAX  DIFF 
command  to  the  file  PAPVAL.SAV  under  lISS  CM  to  insure  Chat  the  unit 
test  ren  correctly. 
l/PO) 

I /CRAP) 

I /SECT  I 
I  SECT) 

I SECTNO] SECTION  4 
I  'PecTNO) 

I  SFCINH  [.SPECIFICATIONS  AND  EVALUATIONS 
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l/SECTNHl 
I  CHAP ) 

(CHAPN0]4.1 
( /CHAPNO) 

jcHAPNnlTctt  Specification 
I /CHAPNM ) 

[POlThe  Unit  Teat  Plan  ia  baae4  on  covering  specific  functionaHty  of  the 
sent  Parser  as  outlined  i~  tire  COS  Development  Specification  (OS)  and  the 
sent  ISO  Be79  reference  manual. 

(/PO) 

|PC]The  Parser  ia  tested  by  using  the  input  files  of  the  NBS  validation 
suite.  These  filet  were  developed  to  test  the  level  of  conformance 
and  the  correctness  of  Parser  implementations  to  the  SCHL  standard. 

Each  validation  suite  test  file  tests  one  specific  feature  of  the  standard. 

The  first  set  of  filet,  listed  in  Appendix  A  and  starting  with  the  letter 
C,  tests  sequences  of  SCnt  language  statements  that  are  valid.  No  errors 
should  be  detected  by  the  Parser  when  parsing  any  of  the  valid  test  cases. 

The  second  set  of  filet,  listed  in  Appendix  B  and  starting  with  the 
letter  I,  are  test  sequences  of  SCHL  language  statements  that  are  invalid 
and  should  produce  an  error  when  they  ate  parsed.  To  execute  the  validation 
suite,  each  file  can  be  parted  individually  by  the  tetter,  or  a  command 
procedure  PAFVAL.COK  can  be  executed  to  parte  all  filet  at  once. 
l/POl 

IPOjThe  validation  suite  it  the  Unit  Test  for  the  EDS  SGML  Parser.  The 
objective  of  the  test  it  to  insure  that  the  SGKi.  Parser  partes  all 
validation  suite  files  in  the  correct  manner. 
l/PO) 

I /CHAP] 

I  CHAP  1 
I CHAPNO 14. 2 
1 /CHAPNO] 

I CHAPNh I  Test ing  Kethods  and  Constraints 
i /CHAPNM I 

jpOlThe  tests  outlined  in  Section  5  can  be  executed  in  any  order.  The  required 
input  is  given  for  each  test  in  the  form  of  a  validation  suite  test  file  name. 

A  list  of  the  test  files  are  given 

in  Appendices  A  t  B.  Appendix  A  contains  those  tests  that  should  run 
without  error,  while  Appendix  B  contains  those  tests  that  should  produce 
sn  error  . 
l/PO) 

tPClThe  tester  can  either  manually  parse  one  file  at  a  time,  or  run  a  command 
file  to  execute  the  entire  validation  suite.  The  name  of  this 
command  file  is  PAPVAb.COn  and  is  under  IISS  Configuration  Management. 

1/POl 

|pC!n:  additional  constraints  are  placed  on  this  unit  test 
besides  those  listed  in  Sections  5.2  and  3.3  of  this  document. 
l/PO) 

I /CHAP] 

[CHAP] 

I CHAPNO] 4. 3 
I /CHAPNO ] 

1 CHAPNH ITest  Progression 
( /CHAPNH ] 

ipO]Thc  validation  suite  test  files  may  be  executed  in  any  order. 
l/PO] 

I /CHAP] 

(CHAP] 

I CHAPNO] 4. 4 
I /CHAPNO) 

ICHAPNHjTest  Evaluation  ' 

l/CKAPNn] 

jpOlThe  NBS  validation  suite  test  files  are  divided  into  two  categories  - 
test  documents  that  should  parse  without  error,  and  test  documents  that 
are  invalid  and  should  produce  an  error.  The  files  that  begin  with  the  letter 
C  should  NOT  produce  any  errors.  The  files  that  begin  with  the  letter  I 
SHOULD  produce  an  error  message. 
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t/POl 

(POIThe  test  retultc  are  evaluated  by  checking  the  Parser  output  to  sake  sure 
that  no  error  nestaget  have  been  generated  lor  C  filet  and  that  error 
aettaget  are  generated  for  all  1  filet. 

I/PO) 

IPOIThe  SGML  Parser  will  stop  parsing  the  test  docunent  and  generate  an  error 
aessage  of  the  forir  ERROR:...  when  an  error  in  the  document  it  foi>nd.  The 
accuracy  of  this  Uriii  Test  Plan  is  dependent  upon  the  observation  by  the  tester 
of  the  output  of  the  Parser. 

l/PO) 

IPOjlf  the  tetter  runt  PARVAL . COM  then  the  output  file  PARVAL.TST  is 
produced.  This  file  may  be  compared  to  the  file  PARVAL.SAV  under  IJSS 
Configuration  Management  using  the  VAX  DIPF  command.  For  the  test 
to  be  sucessfull  the  files  should  match  exactly. 

I/PO) 

l/CHAP) 

(/SECT) 

(SECT) 

I SECTNO)SECTJOK  5 
I/SECTNO) 

1  SECTNh.  ITEST  procedures 
1 /SECTNM ) 

1  CHAP  1 

iCHAPNOJS.l 

i/CHAPNO] 

[CHAPNMlTett  Description 
l/CHAPNM) 

(POIThe  Unit  Test  plan  it  executed  by  parting  all  test  documents  listed  in 
Appendices  A  and  B  and  observing  the  output  of  the  Parser  for  each  test. 

As  mentioned  above,  the  test  documents  listed  in  Appendix  A  are  valid 
SGMU  dccuments  and  should  parte  without  error.  Those  listed  in  Appendix 
B  are  test  documents  that  are  invalid.  The  Parser  should  signal  some 
error  for  each  one  of  the  test  documents  listed  in  Appendix  B. 

I /PC) 
l/CHAP) 

(CHAP) 

|CHAPN0)5.2 

I/CHAPNO) 

(CHAPNM)Test  Control 
I /CHAPNr ) 

jpC)A  list  of  all  validation  suite  test  documents  it  provided  in  Appendices 
A  and  B.  These  test  documents  completely  specify  all  input  files  necessary 
to  test  that  the  EDS  SGML  Parser  can  correctly  parse  documents 
that  conform  to  the  SGML  standard  and  detect  those  documents  that  do  not. 

I/PO) 

l/CHAP] 

(CHAP) 

iCHAPNO)5.3 

I/CHAPNO) 

jcHAPNn)Tctt  Procedures 
l/CHAPNM) 

iPC)To  run  the  Unit  Test  Plan,  the  symbol  SCHL  must  be  correctly  set  up  to 
invoke  execution  of  the  program  SGML. EXE.  Assuming  that  the  symbol  is 
correctly  set,  then  the  tetter  must  execute 
the  following  commands  to  parse  a  test  document  manually: 

I/PO) 

(LIST) 

(IISSET  DEFAULT  (directory  containing  the  validation  suite  files) 

I/I ) 

IIISSGHL  (validation  suite  file  neme) 

1/11 
ID 
I /I) 

I /LIST) 

jpOTo  execute  the  entire  validation  suite  using  the  command  procedure 
rAevAL.con,  the  tester  should  execute  the  following  commands: 
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1 


1/POl 

lllsSET  DEFAULT  (directory  containing  th*  validation  suite  files) 

1/1  ) 

1 1 1S*PAFVAL 

ll)$Dirr  PAPVAL.TST  PAPVAL.SAV 

I /I  I 
(1) 
l/Xl 

(/LIST! 

( PEPOPT I 
(PEPBOOV 

riLE-'g.lia' 

r«T- -TEXT' ) 

1 /PEPBODY 1 
1 /PEPOPT) 

(PEPOPT) 

(PEPBOOV 

FILE-' i . 1 i»  • 

FPT-'TEXT' ) 

(/PEPBODY 1 
(/PEPOPT) 

(/CHAP) 

(/SECT) 

(/BODY) 

( PEAP ) 

(/PEAP) 

(/ICAHUTP) 
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APPENDIX  C 

EDS  Unit  Test  Plan  Source  Document 

The  following  pages  are  computer  listings  of  an  EDS  source 
unit  test  plan  manual. 
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•  </aap^>a 

«/^ei 

(■aftaina  < 

7  . 

nataat  Activiry  faa^ti . 

4  AckafM 

(aa9v^o>l 

( .'sap^c  > 

»»»#>  2-J 

tsapi^'l»>a;)a  S^C  v«Uial»ar-  fwAta  Tati  t*nBiar 

a  i/aaf^« 

1  tprva»»>) 

n^lCW  1 

taftvrvta 

rfsrv  fluaumoBt  . 

«/taactM> 

I  «/Ua%af^» 

C 
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ru*  ts  »AMt»  \J7f  >AJts9  .r>  ;s  14  2;  >m«  >0 

*/ticr.i> 

••cut**srCT:aii  i<  ••cvk*» 

%m*9' 

<»4pr.e>l  l(/cK*pM> 

^  ‘  hit  ?*•••</ CllA«n« ) 

Wilt  T«lt  PIm  <1^  •tlAtlilMk  4A4  fr^wAit** 

ukkd  tfr  test  tAt  kf  tto*  co^Mtar 

•  •  UM  t^C  9*raar  fte  MPC  Tartar  la  ana  c«nf i^tatiar.  itaa  at  Uia 

UliS  IIUI.  htat  (BlA  .«/>s> 

•c%a»' 

t  c«a  pn  e  U  ■  2 « /cMpvM  > 

«cA«prai  fre:act  ftafa.Maraac/altf^w 

(l.ai ' 

4i;>  1'  r^-ttra.*  OeAjaafta’.ian  ti4M«r4a  </vl  > . 

iM:v:ucdo;:  i  u^'a^ar  .tii  «/«i' 

(i;>n:7'  Vit«nM'..oAa:  ft.araarCitatian. 

<«.  •  la! anM".  tar  fraeaii.r^  •  fait  aA4  CM.aa  tyitaaa  •. 

•  '.ar<4a?4  te^ar«.)laa  Matati;  iia/if^fa  ISO  11^1 

;2  OrtaMr  ll«<  </kl> 

•il  '!'  :^ta*^4’.;a^a.  Cr4aflti«'..aa  ?>;  Itaf.Sa r li ta*.;«ri  <wl'Cf2ica 

Oa.'aM'l  *  ac'.i* '  a  ^;r  ^<a  0»<*4aa*t  tata-'cr.Araa 

rarMt>/v;).  Oe\»b«t  l«*.i  (&ta2\'  (/.!> 

a;>'  4  MMtira*  Pauvi.  t‘.aa4ari»  Iritit.ia  <«; > Jaw : ttar^ 

Aat.e<w:  Standard  f«r  lyt^acj  •  Ca^w'«: 

CrapTiCi  «  Miiaf.la  far  i>a  S’.ocafa  ar  9  Trarufar  tf 
din.ra  Oaacr.pi.aa  Ir  f : i  aas:  X/? 

^f^ai  tilt  </il> 

«il>\tl!  ftrv<twMJ  aa•aarc^  Carparattar.  «al>far« 

Sracaaiar  Mar  t  nar  44S2J42*9X  14  ill*  <  .1  > 

'lli'f4  ftructwta:  laaaarU  Corparatiar.  «ul>Vtrtwa. 

Tarp.rwi  Ofaraior  Qa^taat/*^*  OP  42C24400(1A.  14  faftnaar^'  lilt  </^;> 

a  I  Uaak  rw>l£r  •  baatra:  Jawlyiar  Qarwra^ar.  21 
tkraaaacn  far  vja  IftfraMara  &s..aa</ti;>  </il> 

Itrw’.wrai  0>^A.Cf  laaaarcp  CarpataCiaa.  <iaJ>fara 
ftaeaaaar  Oavaiapaant  Ipacif tcataaa«/wl>  .  Di  42e24<^04A.  14  aaSrwry  It4>«/«1> 
</lta'.  < 

a/atwa. 

*msf 

itfiaprM'l  )</«taar-9’ 

«rt>apria  Tara*  aa<  Jwar*«tat>aa**/ea*pna 
«li*t  > 

<  t  }>  <  »  >  Jwar  I  car  SiartAartf  Ca4B  far  Infaraaiiar.  IXarefwnfa  JklCllM/vl>: 

1V«  ccwraciar  aat  paf^Aad  ty  AMS!  a)  4  artd  aaad  pf  aaai  aa^^xar 
awttert  -/ii> 

«*)>  (I*.  >  At  t r hpatat /VI  >  A  Owranaraaiaf  aaad  ta  paalify  aa  aiawaat 
avtkui  a  «M%«ant  «/i2r 


m*  (fciAjim  cai  iamoi  vmiAUO  vtt  2>  ix-atc-ita*  ii  2]  »  »a«a  oo 


f.:*  lujjuas  04.1AW9  -tt:  ttxio  \r7  il  :2«occ*;tr  u  22  •>  par#  I'.a 


<i2><wl>Ci*‘*ctar  l*t«/Vli  A  Mppu-i  af  a  cAaraetar  rapartcira  ant*  a 
raa*  aat  awen  lAat  aacA  cAAtaetar  aa  aaaaca*ta<  waUt  at*  ca4ad 
tafraaaAtataar . </a2» 

<i2>«ul>Ca^-awnd  Dattwan*. </taI>  A  Se»«ar.t  aiuA  My  pantaap  Mial 
caataftt  li^at.  ftapAaca.  ate  ;  </a2> 

(i2> «wl  tCa^gtar  ftrapT-aca  MtaCala  'CQP.x/W*  A  ttafkMrd  tala  farMt 
fat  tit*  t*.a:*f*  ant  ratraav*:  af  partura  Macraptaar. 
uUarMU**.  </a2> 

<a2>  <u!  tCa^titar  PraffAJi  Cafif  ift.r*t;an  Jtap  f9C2U/Vl>:  An  Affrafataar 
af  e»^.;tar  ptefrapa  af  *i«y  af  Utaar  Aaaeiat*  parvaaaw,  lAacti 
aataafaaa  ar  *nA>sa*a  fMctaaat.</i2> 

ta2><wl>Caf\.*afVind  S9C.  J^T^ieat  lanr/vl  > '  Ar.  AoaC  AfplacaiaM  Uaat 
taT>ar*a  d0<'i^a*t'.*  ta  Aa  tenfaraanf  AaCVPanta  .  and  Maa* 

tfarhwa^'.ataer  anata  Uv*  ra^taataManta  af  tAat  lAtarwtaapal 

SlwtAard  i/t3> 

<a2><ui  tCcAtait-ttrartai  t4itar(/ul'  Jv>  tOt  applacataan  ««acA  lAuMt 
U>*  ^*r  ut:*we*'  ‘i^*  ptacaai  af  iaryaftt  craataan  an«  ravt^aar. 
p,  wa.r;  um  danMar.t  typ*  Aafanataaa  aa  a  adMI  far  Mvich 
lay.ca.  a. Manta  aay  Aa  aJacltaMC  vr  t.%a  MrtMni.«/j3> 

<a2>  •«; ’baacr.pt.va  .vrat^<  ,i;>  Irtfarvataar.  aMai  ta  a  Mnaant  uia*. 
anaAiai  ar  appiacataae  ptadta*  ta  pracaaa  Uw  MevMnt .  «/a2> 

<a2- '  >0iruMrt  Oafirjtiar  ■^.  '^l  t  twlai  M'.arm.jvad  t*,  a.*. 

•.«•■  •KO  <<  If*  •••..;  •(  «er»»r.n  »f  • 

parttrwlar  t-,pa  A  tarMar:'.  t^pa  Patan.'.aaa  tAclvMa  a  farva. 
apa^'f'Ca'tar  *<praa*a«  in  a  Mn^ia:  tvpa  Mciarataar.  at  tA* 
a.aaan*  t  pat  a.ana-i  f  a  .at  .tna*..r  k  and  attijAutaa  ard 
r*f*ta(;ak  u*’  ea.'  Aa  r*^i*»a>.t*s  >»  Mraw4  2t  tAata9. 
aaf;.r*:  u*  KkAblArv’  af  th*  aara^r  fat  «r..eA  MTC  dafanaa  CT.a 
tyntai  A  rrt  cat  alat  ivlMa  cawwarta  Uat  daacriwa  lAa 
a*M*t.;»  af  a.awan'.*  aac  attriAwtai  aAd  anv  applicataap 
ccnvaMkir.a  </.«> 

<j2><w.tc.ar*.tatuc  ftaruantatian  Pyataa  lESAx/vi):  Ar  aptwffatad  aat 
af  acftvira  tacla  and  *ptl:cati*n  pra^rap*  afticS.  aparata  ^an  a 
dcr^"  urcje*-  v*:ka>.l  tt*y*»  cf  a  paCNWant  Ijf*  r/:la 

canj.ktin^  af  ait*.:r>t  sraa*.  ;r>t  *:  *«  i  1  > '  (araattaat,  apatiAf- 

atcrapa.  and  tjamafara/tt  i/i2> 

<i2>4 wl tt.anant  I /N.1  >  ’  A  ca^pnari  at  Uta  kitrareAktal  itrvetara  dafu'^ad 
Ay  a  aDc*jMn’.  t)pa  Pafinit.an  .»  kdartifiad  aa  a  danaart 
uiatanc*  Ay  daacfkptJ^a  nara^^.  aawallv  *  atart^taf  and  adk^tAf ■  </a2i 

<t2><bl>t:*Mni  Daclaratiant/VJt  -  Aparkt*  daciarataap  UMt  daPlaaM 

tit*  forM.  apa^  1  f •  r* lan  at  tita  par*  af  an  alaMnt  typa 

daf.^itkon  tAat  Aaa.a  vitit  Uw  e»nt*nt  and  MrA^  MitiPjaataap .  */i2* 

4t«><al>bB‘.tr>-(/v:>  '  A  callartaan  at  cAarartara  that  can  M  rafaranrad 

aa  a  «it.  ^/tZr 

ratxwltMtkry  bar :  arat  tan  t  >  a  aaravp  daclaraiaa*  that  aaatfna  an  MP&  Paw 
te  ar  antaty  ta  that  it  cab  Aa  rafarancad  </i2> 

tkixaltDt'.itv  Mfttanca(/wli  A  rafaravtca  that  *B  radl*<*^  *¥  pptaty.</A2> 

4i2><al)f;ald</Vl>  .  dipaaiiana'  apar*  **  *  tanwM]  aciaaw.l/*l» 

«»2xt*:  tfarwi -vl  >  A  atrumbiatf  vta*  «htcA  Pa)  Aa  UMPtad  ap  wAWdAM  at 
athat  farpa  A  far*  la  caa^aad  af  faalda  TMaa  t*alda  mj  Ap 


PiJa  US  tAAlCA  (rViFAAlV  VTr.21  12^C>1PI'  14. 21  ->  Papa .  dC4 
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ruuuo  CBS  r^MO  \,Tt  'JTf  :}  —  »««• 


Dafiiutivn  <rD  </hi  >  f9r»  Atfift.t.vn  VAKfu«t«  *fk«f 

It  i«  r**i  tt  9^  %Mm  r*rm 

«iI><uJ)r*r«  D»(ifut»«r>  iraixiAili  •fiicA 

•lactrMuc  (•rta  </t9> 

Sditvt  trt't/ul>.  A  lufett*.  •;  Um  tits  U««i  tr* 

k»  te  cr*«it  tfaftrutiOAA  •f  forma  T^o  ft  conAitti  of  U»o 

form*  Ptaww  form  C4atot  antf  UM  forma  Torriri^  Copilot .  i/ila 

«.3>(^>ferm  ft40torcfiy</v.l>  •  A  fropfeit  ro^rottf  totaort  of  t*o  «ojr  xr. 

fcrma  atoma  oed  v^MMt  oto  loUtoC  to  UMit  ^ror.*. 
form  4/a2* 

<i:>(u:>f€rm  Urt^t*  <rUf’<A<l>'  A  At^ot  of  tiM  Pi  tf^t 

cora.ata  c?  «  WtcA  jprecoaa  t^t  kceotta  •  toraoi  cf  form 
Ao^ir.atiOt  ;Ar4^4a^o  atatomortA  trid  pro(^roa  form  4ifaruiaer. 
falot  oa  OMtpwt . </i2> 

<a}>  <«.! 'far*  frosoator  A  tatfaa*.  a?  Um  SSIS  Jaar  latorfaco 

tAo*  raraiata  of  a  to*,  of  sal.osl*  oaorw'.iOA-taaM  ;oi.;iAOk 
aoai.ot.a  *.o  or.  App^iSat^on  9;e«;4A  f<r  for#  prccoaa;j^f 

(i}><.l>farBi  tr^vor  form  C^«or  ifSft  '/^>-  A  auMot  af  tf.o  PC  krtttor 
<aoa;ata  e!  a  tcrma^ri'^r  a^^lkcataa^  oaod  ic  croata  form 
Dofarut.oA  f.;ok  ;.rtaractwa;.  <.4:> 

(a}>«w:>ft«Aora:  24oAtaflar4/*4;>  A  mm  UMt  i«o<«ttfioa  tAo  olomar.t  of  or. 

oiomoft  Wi2> 

(|}>  <ol>C!  </4l )  :  mrnfiotat  imoAtifia; 

fjr.rttor  A«rooo«/%;>-  Bia  ftra;  acroor  VM*.  ia  taap^ayod 
Aflat  Utv  2t  Al;o<^  Uio  taior  to  tAo  f,tftet>oA  t« 

areata  ara  lAa  Aooiea  f)^  ond  Awea  iwiam  an  «tt«rr  tc  ««r«  «  a2> 

<i:Mu]>:.<\tof ’atad  Xffarmatioti  Awppori  tvaloA  (::il  it  z'^:  > ;  A  tatt 
roar<i<ina  onviroAMni  wiod  tr  Ar<«ait<dat#  ^omenairaca  orM  Coat 
Uo  eanta^'.i  cf  inf9rma;;8r.  MAOfooo't  are  ir.ferMUor. 
or‘.a9:«t.af^  u*  lAa  aonioit  cf  Aotetpata  Ao.'Mf  aeiw :  •/ f  tHa  ;:SS 

adJ.-aaiai  tAo  ^tabioma  of  aAtodrattort  «(  mata  :«at«Ant  at. 
iMtatoAo^ooui  4aia  kaaaa  a%4^no4  Ay  iaotaroyomoomA  ctMUMatori 
antofeoMoctod  ota  a  2mca:  Aaoo  Aot«ora.</4ji 

«a}>(u:  I !iom<  •  A  mar  4acoayoaot«a  araa  of  a  form  tr  oCiica 
terA-<o4aa  moaefaptavo  tot*,  mo)  Ao  piatod  and  um  only  AafUMO 
aroaa  oOMia  tioor  Aota  My  Aa  u^t/ovtpkit .  </t2> 

(a2> tmX >UyMit  ftyloi/kli  Vm  apoetf aaatiar  of  format  aM  ptoaontattor. 
for  logical  olomonta  > 

< » } ) « m2 > LoyoMt  itrvctwrot /v2 > :  tta  AtorarcAy  Af  al*  loyrngt  olmmonta 
tpofoa.  tr»am$,  AiocAa.  otc.i  for  a  Amewant .  </of> 

caSxmitlmpkCA'l  ftivctwro«/m2»  TtM  Aaorare^y  of  aU  toficAl  Alomanta 
(parof tapfa  .  amettona.  otc.;  vttAor  a  Aoemmort. 

<a2Mm2<AarkMp(Al> :  Tmit  CAat  aa  aAAod  to  AM  4ata  af  a  #oc^onx  in  orAat  tc  t 

■  tomboy 

aafarmo*.;Mi  aAomt  «t.</a2» 

o}>  to.  >Aort4#  tlofU*atat»ort/ml)  :  A  foatoro  af  AOK.  tAat  allowa  msrkgp  to  Ao 
moA^mtaod  py  AAortomaAf  ot  omittaaA  tapa.  or  aAortomtiap  ortaty  rafatoncoa ■  </a2> 


Paia  lAAOAJBa.CH  PAAA0  OTTIPAMS .  VIT.  PA  I^•«C>1P•7  ja;P2  —  Papa  t9i 


Pkla  (AAaJirA  BA  fOAlD  m  iPAW0  TTP .  2A  IP-Kt-lAl**  ;4  p»«0  CA(  T 

otarAord  moaaoao  .400  er<  Uio  tormoTkOi  acroorv  Haaaapoi  ora  uood 
to  «orr.  cf  orrert  01  piovtpa  otAor  moor  amformataon  t/i3> 

ct2><wl»*maaa%a  Ur*'A.;>  A  iaiw  «i  Um  tormaiM*  actoor.  uxa:  at  uaat 

to  tbop^O)  moaaatot  «/a2>  I 

4t2>«o2>0poratant  pvatao  'OA'</Vl>:  Saftmaro  tuppUoA  v-.U.  a  cmoipwiar 

«r.ac^  allcoa  at  C<  a^porvita  iCa  o«oi  oporaiaorm  ar.d  porMpa 

Accoaa  ta  Mt^ata  facalataoa  au0  aa  osaar^'  apd  panpParo^a  </a2> 

<i2>«Ml>Po0« A«2>  laatareo  of  forma  o»  oiPioma  Umt  arm  croatod 
MkortotMt  0  form  la  odPof  to  a  v^pPbo  i/t2> 

<t2><ul>N«Lr9  apd  Arrall t»9«  AU  > :  A  Mtted  i%a0  aXlP^M  A  farm  lo 
Aontaui  pora  ^ta  tMn  car  Ao  Akapioyad  At  am  tiPo  tnUv 
ptoviAiofm  far  vio«;j‘.|  air^  peftkOA  af  tA#  0tA  Auffor.</^«) 

An  opp2;ea*,;en  profrap  VAat  tetarm^oa  hoo  cloaoiy 
0  dacjpa^t  ec^fsrmt  to  a  AorMo*'*  MtoJutiPP  «lu0  PofiMa 

a  ap  '  t.c  Aormportaiiar.  atanoord  (/;«> 

4.2>«4l>^;'a;.eo:  bovirai/Llk  A  Aor^ro  tartumol .  (/a3i 

«.2.(.;>Prov;awft  ^4raar  PcatttoAt /ml > :  tSa  pAaataon  af  um  ruraor  Mmr 
fto.«a-.ft  odi*.  eoMar.d  wat  ttamad  i/i3> 

<.2>>..»Cm«l;f;oC  kopo<.'m;>  TM  aopo  af  a  taro,  atoa  ot  •»aA»o 
proeoaoc  p.  u.o  naoraru.,  po*.n  ac  Umi  at  aa  tpugooly 
aPoMifaod  '/a^) 

•  >f  lonAatr  AoMtalaiod  Vrkdp  Ipr.^opo  'S0Ci«aU>  A  lAfkfmato 

fot  ooacriCioc  AermooM  a*.rvrtwro»  eanaaatani  of  0arnpta*o 
p*r».;  at  aaooc  tc  a  pocupoft  to  anCtato  Mvoto  lo$;ca: 

o;oPo*(a  Owen  at  aaetaor.i  and  parafraprt  Po^aA  APd  oPd.  i/a3> 

«a}><t;l>Aakfftr»<  >  A  fora  Utot  aa  uaod  va^.ar.  Aro*UMr  tara 

«a2>4..>tac->*wr  >a;;ar*.;>’0  Mtcvp  afidaBAt^Pt  Um  Atari  a;  or.J  of  a 

lofaro;  olopon:  •/>;> 

<a3><wl  >7aAt*: ' >  Af  appiaeataar  prapra*  %P.acn  prev.paa  a  McAoPaaa 
for  autOMtaraio  tapfanf  aiaatanf  «»rtaapu  itfaacA  A«va  ppon 
craatod  «mtd  procataaPt  ayatopa.  i/a2> 

(a3MwJ>laar  Xr.tarfaea  Vt>(A»2)  HAS  that  cos'.roia 

waat  a  taraatM)  ar.d  artarfaeai  ir.v>  Um  latt  af  tho  ayatoa  Tbo 
C7  coruaata  of  c«m  pojor  aicPtyatopo  IAm  Uoor  iPtacfato 
fiovaloppont  tyataa  (tfSvi  aM  Um  Uaoc  lAtorfaco  HaPopappAt 
tymtop  am;  .i/a3> 

<a2»«mJ)Coo:  tr.torfaco  rwMfopont  Pyatop  IV90maU>:  TAm  rtpt-taM  Cl. 

3t  romraoto  of  tAa  P»r»  Proeoaaor,  Aar^yof  Tormapol.  Applacataori 
XPtorfoto.  Uko  Uoot  XPtorfoco  Aorwteoa.  m4  tPo  Tact  t4atac.</a2> 

ciSxmlavaoT  IMorfaro  tor%acot  rtTXtuAUa.'  A  aalaatt  af  tPo  lltl  Uaar 
iPtorfota  tPat  rar.o;iia  of  a  porAafo  of  routanoa  Uaat  at#  iiaora 
ar  coptrcllar.a  tfca^t  ar>«a  rofMon*.  ft  aPelkaAoa  amaaopo 
popofomor.'. .  eao.nt»  paaawprp.  oPd  O0Ucauop  tefaPatton 
oot%-tcoa  t/a2> 

<*2><«U>vaor  friar  faro /v*  rt«aol  Tarm.iM:  latotfoeo  iCTAfTC  I  <A*1* 

AftouMr  mopt  fer  lAa  Waor  Xptorfoco.  (/a2> 

<a}><wl»«tn«aol  Torataal  A  akJoaot  pf  iPo  XIU  Baot  Iptorfoeo 

UMt  porfarmo  Um  tPtorfarana  Aotow.  Aafforamt  tarmaaola  ar.d 


faU:  tlPAlUO  Caa  fAAS0  miAAMB  XfTA.  IA  U««B€-I>|7  i«:31  «»  K0 :  AM 


A 
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T 


ti.9  iiMuo  tat  tAiuroi  vT»’,fAKOi  'rrf  2I  n«acc-:ti~  ;4.a3  —  »m* 

vtucA  M  »4ippcrt«4  ^  *.^«  'Ji 

•  •f‘.««r*  MfeiCli  c«naiitwt*i  U*  «ir*.w4i  •tfan.tXaM 

•p«:ifte  i*rft.''>AU  ar*  Uv*.’  Mpp«4  t>.«  vartwal  taratM!. 

«)-  a^CifiC  aaftwar*  acaui*!  wraitsr.  far  ty^  •i 

!••:  larm^Ml  Val) 

Tar^fMl  Xittarfac*  4Vr:)(/wI)  Mi  iiit«rf*c« 

t«  \M  trr  </i2i 

<a2> iiiJ >ViaMw( Ail> '  nfniaii  traa  if  •  tarmaMl  aciMr.  m  Miiit 
faim  a*^'  ^.acaC  at  n*->taaa  </i2> 

^M4«r(/ul>:  A  laeilaty  aluch  Um  lallMkai  te 

M  MA.^«ata4  Ci««  *A^  «f  wj^4»w«  Um  «•>«(•  mi 

4r  ap^l.catkar  as  naw*^;  CM  petitiar  af  a  fan  a 

wir.M*  It  it  ^ri  at  tha  far*  >raeaaicr .  t/i2i 
</2.at ' 

«/CM»> 

i/aact 


iaan » 

* » •  ?v- a>n*I*  ?*/aat«nc' 

<aa?*M^ar-T^^O>*7  JA:%'S?‘/>/»ae*.Aa< 

<*ar> 

|(/cfi4pna> 

iflMpra  Italaaaft  af  tfataa*.  . 

iaC>ea.r;nf  lyataa  4Bv«^»paB*\  V«a  caapw'.ar  (ra^raju  «ata  laataS 
frat'***^**^}*  ^Wtcx.a^l.t)  «a«  .ncraMAta.iy  taata4  anl  aa  avra 

4»a9a««ra<  9j  V^i•  taa*.in|  Uta  aat*.«ara  «a»  cacractatf 

itaniaf  iKiM  far  t.*>a  ta^a^a^nt  af  tita  tSI  MfC.  faraar  Ma  a 
»a;aa:  ^laMi*.atiCf  fat  t^a  eparatiaa  vyatM  4a«*fa^  9^  tM  fla*.;<na. 

t#;aa.  af  Sta/k«ar<i  <fl|$  a»  9«r^.  af  CJCS  iftitaatiaa.  Far  Ctt .  tM  Fataa; 
aai  9BrtM  fraa  r%>Xt  la  v>a  afaratifif  ayataM  awT-ycrtad  9^-  2211  tha 

caM  aa»  9arta4  cJMr.fai  «ata  M4a  to  a«i9..^a’.a  IM  uaa  af  (aa^tary  fiiaa 
III  MJMir  9wia .  Ml  atM  ai^iiMai  fMctiaia.ity  9aa9al  la 

<l^if9.a  9W  aiao  4ava;cp*<  ar  MC.  Faraar  aa;44ataar>  awata  rartfaatjrif  •t 
a  a\iMar  af  fi*as  lAat  taat  apaa.fic  fii9»r'.;aAal«'.y  aitlliMl  in  tfia  9tfC 
aiMlafl  2K  l•''ll  ^y^a  valilaiia*  awita  viU  aarva  aa  Um  kaiia  far 
IM  CC»  Faraar  U^t  Taa:  Fiv.  </>C> 


«MaF> 

<c9a^>  2  ■  2< /«taa9a« ' 

(OMpMrFrataat  Ar^tviT)-  W»Uli«/MayF9H 

ifliiyM  Of  99C  Faroat  aweraiifw^ly  9a«aal  IM  m  aali4altar.  avuia-  A  fa« 
9*Mf  arrar*  Mra  fmmd  in  Ma  vaiiMiian  at^tia  fi;aa  lAavaalvaa  Ml  lAaaa 
Mra  catraciatf .  </>C> 

t/iAaf  > 

4/a««t» 

taaati 

<oariM<ttCTTaH  l</tarviai 
<aactM>tTf^9'  XtOjrgIM*  /aaciif* 


F«ja  |■feaMa»  OK  FAAia.lffF jFaM a  VTF.  21 


12>4BC-lfl''  14.22 


9aM  M? 
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Ftia  lUMjrS  tX  FMAO  '.*T9'FAFJ9  VTF  2S  22*K:>lfl*t  la  If  —  Fafa  Kl 

isTinMa'^ </aAa9M » 

(MapMviyata*  Mac  a  lytiM  <  /claa999 » 

<99>f9a  Mac  Faiaat  la  Um  aa^ahant  af  tha  tiactrM.ic  baeMMiatiaa  tyataa 
that  vaiiMraa  tha  fa^ical  atrwctkta  af  a  UrMar*  afainat  a  f:o»'iau2y  9ui^: 
KA.  Xryaar.t  Tv^  XfiRil^ar..  2t  ;^abraa  tha*.  tha  9a»a;iF*.kva  aarr^  la  lAa 
MCuaaM  ear.fcr^i  to  tha  oo*.  cf  rwla»  aafanaa  |ry  liio  0Tt  Ttio  9X  Mto  '•iTiaa 
«*Mt  faaor^e  ilar.iifiara  ata  va.tl  a:  afty  ^aint  an  tha  Aanaant  Ml  haw  hhh>' 
tiMi  ihay  aay  ac9ur.<^> 


«90>Xh  attd;*.iar  ta  vajihatini  tF.a  aarr^p  tha  Faraar  alia  caavaru  tha  hacMaM 
ta  ata  f^Ky  aaraac  ataia  Fraraiatni  ail  Shttty  rafarancat.  AttriAMiaa 
aM  atpahaa  ail  a^rtaiial  faitar.:  iMttifiara  taMl  v.iAir.  tha  ita«tMant . </>0> 

4/dM9* 


4eha9> 

iChayM  >  2 . 2 « /ehaxi  * 

4ehapha>7aatinc  icha^Jat/ihapfw  • 

<93>Sihca  tha  991  aal.Cat.ar  a..*.a  ta  tha  baaia  far  tha  Faraar  last  ylar.. 
aaacwtian  af  ihit  i#:i;  tatt  f**''  •*  MyartAar-t  uyaR  any  athat  cahyahtMa 
af  atlhar  B1  ct  IfSl  t^y: 

</fihaF> 

tchay* 

4ChaM4  * )  .It/ahaFRa' 

4cha^<fita;  l^catian  Yaatih^' ^itaF49»> 

4y2>ihaaa  taitt  af  tha  Faraar  ta^atra  tha  lallMiM ■  </>Cr 

4 1  tr*.  > 

A^t  Farca  VAX.  tar^iMia  a^yartal  h^-  tha  Virtaai  Tai%iha2t/i> 

4*»  </*> 

«t»lw99crt  laftaara  C  ryh*tiha  2ihratiaa(/i> 

ii»  </*» 

<i>F«raahha;  ana  ihiafraiat  iMuXtar  vith  8*</i> 

«i»  t/»» 

ci>TiaiAih(  tha  tSI  tfaar  !iani»a:  ha»  haan  yrtviaaaly  9a2taaiaA«/i> 
n*  </i> 

«i*fia2iwarhhia«:  tiia  99^  Faraar  9C</1> 

41>  t/»> 

4t>ta»t  Malarial*:  All  taau  ara  rwv  uaihf  tha  nt  Mft.  aaliAitiM 
*Mita  fiJiaa'/i> 

41>  4/t> 

ctrlaeuxicr  eahiiAaratiMa  ■a9a.(/a> 

41>  4/l> 

«/)>ai> 

4/aMar> 

iflhaF> 

4  eMp»a  >  2  .  a « /Chaanc » 

4ahaara  iMoaq-Mrt  l«rat>ar  Taatinf «/eMafnh> 

49e»7r.a  ta9t.ita«ani»  Jiatal  aha -a  mitt  ha  ha*.  9m  caMhi^  ytara^ra 
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vrf:7i 


It  :?  C9t 


fil*  fWAJuo  eat  rAM0  vrrfwaot  trr.ii 


14  2:  —  9:t 


?>!•  fil*  ?rr  CAT  ut«r  »«  c*^4r«0  uaiftf  U>«  VMt  91fV 

W  tc  fA^'Al  AAV  wi#ir  2ItS  Ot  t»  «a«wf*  tAJt 

t»*i  i«A  c»rf*cily  </^C> 


<••« » 

<»*rvM kfXmor  4</»«rt/w) 

«««rtA*  cfcr:r:cAriaN<  M*r  cvAuiKn0tt</c*cua^ 

«cMr  > 

'JMt  T«»t  y.an  i»  b«k«;  en  e^vcrmf  tpvtifif  f«trtiarL«.jt«  e*  uf 
•!  ;?  t.N«  C21  S;«c  i  f  J  :*;;eA  ttt  4aC  Cv« 

*9^  IK  It'l  itfarkr-.s*  Mnwa.  </pC. 

•  >ar»«?  it  hs  MCin^  t/.«  ini^r  tf  tst  ns 

TS***  f.;«.  •.•»*.  -t/*l  cf  cer.fcrM*?* 

«*te  th*  carivrucai  if  >•*»•>  « ar  t  m  im  tia^^ts 

C«.'*  v«.iia;;en  a.^t*  (•$;  !t.0  {•ata  »p»ejtic  {•txyt*  »!  tf.*  tttfitdte 

TS«  t.ti'  a«t  af  til«a  i.c  A  afti  ataftifi^  «;t^  ui*  .cttAr 

6  a*^*i;ti  •;  itatMM^ta  U^t  at*  fie  •;(e;a 

aKA<.;e  to  totar.aS  %>;■  Vha  Aaiaar  i^a*  aara^r^  ••  tfwi  •«;.<  I***.  €*»•• 

?v»«  aaeorj  aa-.  c!  fa.aa.  Uav*<  I  ai>:  a:a:t^<4  &Im 

;at‘.at  :.  ai*  tait  aai^ncaa  a!  •«?^f^afa  aia'.a*to«.a  V-at  ara  anvaltl 

a*>4  ar>a^;a  ;rato«a  u  araer  itoan  oay  ara  faraaS  Ta  aaarw'.a  Ua  .a.«tot;ra> 

•  «;Ta  aa;r  f^ia  car  to  tor«««  tac^vitoali)  Uia  taa:#r  ar  a 

^raaa^wra  SBa*  <v  to  aaacwtM  ca  to'aa  al.  faUa  at  atoa  </»:• 

r^>^a  waiitot^an  aaata  aa  Vto  w.it  taat  far  tto  Rtf  tsac  9ataai  ■  ^a 
cs:a:;iva  <?  tna  tait  ;t  t.*  tniwta  Xtf.  t/a  l»C  ;i  (-a'l*! 

»a.i«a’.4cr  a^iia  (.iaa  ar  ua  aaf:aet  Mnrat .  «/p; > 


<cto»> 

ictoyne  >4  7</e*iapna  • 

<cto?«%A)?aatans  tot/tato  ae«  Catottaia.ta</c\apr«* 

tp^iT^a  taata  awtlkftatf  an  Sactaan  i  «aa  to  aiacvtatf  aa  aa*'/  artor.  Tto  ra4^lraj 
anfw-  *•  favan  far  aacn  laat  aa  uta  far«  a(  a  v4;a4a*.aan  awiU  taat  taU  aaaa. 

A  laat  a(  Uia  taat  lalaa  era  f;van 

XT  Apto^Aicai  Ait  A^to*<Ui  A  cantaa/Lt  ttoaa  taata  Uiat  Atoaaltf  nr 
a^Ua^*.  after  tr.*;#  A^aaAaa  |  canutM  Viaaa  taata  lAat  AAawltf  pratoca 
V  arrar  t/pCt 

i.fCtry00  faatar  ea't  aactor  torualJr  to^**  At  *  laaa  at  n»  a  CMtoA.*\4 

ti,0  t<  aaacwta  t/ia  artara  *alitotato  a^ata.  9w  itoto  af  thaa 

ee^Ana  (ala  aa  IMtoAL  Oto  An«  aa  itotor  lUS  CtofatotAtaan  fltoafa«nt ■  «/y0> 

4V?>to  aAditaaina:  ranatiaarta  at*  flacatf  ar.  tAat  «v;*.  taat 
toaitoa  4naaa  laataC  an  Aaeiaaaia  S  I  aM  J.)  af  Uiaa  toewant 


tenap' 

ictopna  >  a .  >  (/chatoP  > 

«chatoai>7aat  Pfa^faaaaaa«/ctofar» 

aalatotaan  ttaata  taat  (alaa  My  to  aiacwta^  lA  aaay  artot.e^Oi 


4Clkap> 

(cnapAA'A  ai/toapna* 

«chapn»>?aat  tval»atim(/toatoB) 

«p(>fto  ni  va'.aAataa*  awita  taat  (alaa  ara  towatod  inta  taa  catafotaaa  • 
taat  MnMnta  tAat  ahaMlt  pata*  vatAoy'.  arrer  a.*0  taat  tocManta  ttot 
ara  inva.itf  aAtf  aAa^itf  pra^yfv  aa  arrar  fto  filaa  ttoi  tof^c  aatA  tAa  lattar 
e  atoyia  KT  pra^ra  ary  artata  fto  (alaa  ttot  tofaa  valA  tAa  latta:  ] 

SttXLt  pra^ea  an  arrar  toiaapa 


<pC>tSa  taat  r«awlia  ata  avalaatai  ty  toacfeLAf  tto  Varaar  totput  la  Mka  pyra 
that  na  a;t»r  aaaaapaa  to--a  toan  f4^*tatad  (cr  C  (ilaa  and  that  arrat 
■aaaatat  at*  fanaiataP  (ar  all  t  (alat.«i^> 

ipC'fSa  Paraar  tr.y,  nap  pariinp  tAa  taiS  doc*toan*.  and  fanarata  ar.  arrar 

■aaaafa  af  tAa  fara  OtAOP  ■  «tf4an  an  arrar  an  tto  tomaart  la  (aynC  ^.a 
arr.«.'ar>  af  th.a  *#(*  fiar  ;a  toranoa.*.:  tto  aaaarvat^ac  to  tto  tartar 

af  tr.a  a.tp.*  e*  tto  Paraar 

(p:>:*  tto  tartar  runt  PAPvrc  tl.ar  tr.a  autpet  f.la  PAT/A^  Tft  ;• 
prtp^rac  ^ta  f.la  t«  CMQ^rad  tt  ‘.m  (a. a  FAX'LL  to'  ^aai  ms 
Car  f  .C.ral.  tf  v.ataaar-.  wt.??  -ta  VAA  tiff  cowarC  Par  Uta  taat 
ta  aa  awcataf...  tna  f.lat  ar.ayic  aattb  aaart ly ■  </Tr > 


4tart» 

taactoa'ltinto  $»/iann.a. 

<aaetrja:TUT  PPOCt0>JRX4  • /tanM  > 

<ctop» 

<  e  to  pn  e  >  $  ■ ;  < /cAapto  > 

4CtopMk>Taat  ftaacfaptiMr^Ctoi— > 

<y)0>Tto  trwt  Taat  plan  ta  aaaevtad  »y  parttof  all  taat  tonaaaftta  laatto  to 
Ap^nCtrat  A  and  I  and  atoarvtnp  tto  atlptl  t(  tto  Partar  (ar  mcp  taat. 
to  aartactod  aPava .  tto  taat  d•c^Man^a  Uatad  id  Apparktoa  A  ara  aalad 
•CAC  dcn«ant»  arid  adavld  pat»a  a^tnayi  arrar.  Itiaaa  Uatad  an  Afp«a4aB 
p  ata  taa*.  doryaant*  tiia'.  ara  tovaUd  (to  Paraar  atould  ai^l  a«M 
arrar  far  aa:A  ara  of  U>a  taat  dnoManta  Uatad  an  AfpaAtoa  |.</p0> 


rctopr 

«ctopnc  > } . )  (/CPiapna  * 

<ctopa»>Taat  CMitral</^0*PM> 

<pd>A  laat  af  all  vaUdaiiar  awata  taat  ia«MMita  aa  pravtMd  ua  AppMitowa 
A  and  f  ^raa  taat  der^Mar.ta  ra^lataiy  apvcify  ail  (rlaa  toraaaar)' 

tc  taat  tnat  tn*  COP  tC^  Paraar  can  carractly  paraa  tostoMr.ta 
ttot  eaiifar%  ta  tto  MaC  atandatd  and  Mtact  ttoaa  Mn^Ata  ttot  4a 
</cftap* 

<ctop> 

ectopto  >  $ .  )< /cPiapna » 

<ctopito>Taat  Piacadtraai/ctoM** 


ap0»Ta  nr.  tto  teat  Taat  Plan  tha  art^Al 


.  Mat  to  Miractly  aat  t#  ta 


.  p*Ma .  tPtt  I PAM01 .  vn .  2s 


ll^C'iti'P  la;]]  ^  Pa«a  tdt 


raia:  |■toMXS.Ca»  PAM0  9TT|PAM0.tfXT;aS 


UHSC'tPIT  l«:2(  —  Pato  Pit 
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filt  IIMJO  VTf  3%  D-lftC-ltP  II. 2}  f.f*  621 


Mrrvnly  .  UMf.  uw  SMit  •••cvt* 

tiM  f*«2»vy«|  i*  •Miu«2)y '■</>€< 

clait » 

CKTM,'^  (4ir*ct*ry  CMit4aAaftf  tiM  «4la4*taM  mtit* 

(a»IMlC  (««l;4«ttM  luat*  til* 

<4*  C/l» 

«/l 4*t> 

ctCiT*  vs*  Mt4C«  Vftl»4*tt*4  •aut*  Uw  c««h4Ad  ^r»C4A4f* 

OR.  t/t«  t«lt*t  AfMwiC  •»4CWt»  tiM  fci;4v^rkf  C•M4^4*  «/T9> 

<a>ISrT  VKTKJ'JT  (4kr«rt*f)'  e«r.t4aRi»t  th*  iwlatfitiM  ttoit* 

(a»lc:fT  ^Airvio.  nr  MT.IC  &lkV4/A» 

ti  *  «/»> 
t/iait  > 

<r«pe;x - 

</t«pcrt) 

4r«p4f*.) 

</r«7fte#y> 


«/Mn* 


</AC4auX9> 


fii*  lUkMo  cas.^AMO  2«;i;  —  ai2 
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APPENDIX  D 

DECDX 


The  following  pages  are  computer  listings  of  EDS  Tagger 
information.  The  first  listing,  DECDX. L,  is  that  of  the 
template  for  all  DECDX  documents  to  be  tagged  using  the  Tagger 
facilities.  The  second  listing  is  a  listing  that  was  generated 
using  the  DECDX. L  as  a  template  and  running  the  Autotag  program. 
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ril*  DECDX.L 

This  file  it  the  template  for  all  DECDX  docunentt  to  tv  tagged. 

%p  3000 

\[ 

/*  DECDX  -  DEC  OX  document  tcBplatc 
* 

*  Description 

*  Th:a  lex  touicc  file  it  utcd  at  a  ttcplate  for  DEC  DX 
docunentt.  It 

*  would  De  loaded  at  the  start  of  cresting  a  tagger  for  a 
particular 

*  document  and  taved  under  a  different  name  relavcnt  to  the 
docuaent . 

*/ 

linclude  <ttdtyp.h> 

•include  <ttdio.h> 

•include  <ctlcht.h> 

•include  retype. h> 

•undef  input 

•  unde f  unp.t 

•  undef  YYLr.AX 
•undef  ECHO 

•define  YYtnAX  ICOOO 

•define  ECKO  echciyytextl 

•define  Eh:T(x)  f p r i n t f i out f p .  “Et",  x) 

•define  yywrapi )  1 

static  yylooK),  yybaek(),  yyinput(),  yyoutput(),  yyunput(): 
extern  Tlli  •outtp; 


%1 

bold_on  ’(•* 

bold_off  ’IX" 

und_on  *(•" 

und  off  ’  ( S ■ 

tup~on  ’  i  )  ’ 

tup'off  ■(;■ 

sub  on  *(♦" 

sub“off 

aux~on  • j .  » 

aux“off  ’It* 

dx  tilde  •!>’ 

dx“:  brace  ’I;’ 

ds'’r~btace  ’!•’ 

dx'bat  •!<* 

lin_*od  'IC' 

coB~en  “IH" 

dx  tab  *|I’ 

dx~nl  ’U* 
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31 


<l*_f  f 

coiE_of  f 

sp«ce 

hyphen 

wv_hyphen 

*i~~eol 

p«9e_««rk 

bteakinq  hyphen 

pa  ra9r<p?i_Ba  rk 

center 

rulcr_Bodif  icd 
tde  on 
tde~o*i 
tde_char 
any~char 

( I  *  I N I |d*_tatl ; 

vhitc  apace 

«l 


■|L* 

'|H* 


( aux_onl (und_on 1 { dx_nl ) 
j  aux_on)  1  d.’'_nl  1  (  aux”of  1  ) 

(au»_on) (dx~if  j (aux_olf ) 

1 «ux_on 1 1  hyphen  1  I aux_of f  ) 
j*up_ori fdx_nl ) {aup_off  } 

(aub  on) (dx~nl ) (aub^olf 1 
(uol3_en 1 ) lTn_»Dd ) (Beld_of  f ) 

( coc_en) i apace } *a  S" ( co»_of  f ) 
j  coei_or. i  i  apace  j  *S5*  i  coB~of  £  ) 

( coc_on j { apace  j  <  .  { com_o?f | 

|dx_bar) I (dx_l^brace) ; )dx_t_brace) ) { dx_ti Ide ) ) 
({apace!  Tdx  tab))  ~  “  ~ 


( 

/•  anythinq  clae  •/ 

if  (yytext(01  -•  '1'  II  yytextIC)  —  '{')  yyaoret); 
elae  CCKO; 

) 


atatie  char  but  I YYLnAX  ] ,  ‘pbuf  «  buf; 
int  charyy  •  0; 
atatie  input ( ) 

( 

chat  c; 


If  (pbuf  >  buf)  c  -  ‘pbuf — ; 
elae  c  «  iilex(); 
return  c  ; 

I 

atatie  unput(c) 
cha  r  c ; 

( 

•■♦♦pbuf  -  c; 

1 

atatie  yyreject( ) 

C 

extern  int  yylenqth; 

while  (yylenqth  >  01 

•♦♦pbu£  •  yytextl — yylenqth): 

) 
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rile  DXUTP.L 

This  file  it  the  result  of  running  the  AliTOTAC  progrsir,  steps  2 
though  32  of  this  unit  test  plan. 

tp  3000 

M 

/*  DECOX  -  DEC  DX  document  template 

« 

•  Description 

•  This  lex  source  file  is  used  as  a  template  fer  DEC  DX 
documents.  It 

•  would  be  loaded  at  the  start  of  creating  a  tagger  for  a 
particular 

•  document  and  saved  under  a  different  name  relavent  to  the 
document . 

•/ 

•include  <stdtyp.h> 

•  include  <stdio.h) 

•  1 nc 1 ude  <ctlchr .h> 

•include  <ctype.h> 

•undef  input 
•undef  unput 
•undef  YYLKAX 
•undef  ECHO 

•define  YYLRAX  10000 
•define  ECHO  echo(yytext) 

•  define  Er.lT(x)  f  pt  int  f  ( outf  p,  *%s’.  x) 

•  define  yywrapi  )  1 

static  yylooK(),  yyback(),  yyinput(),  yyoutputi),  yyunputt); 
extern  FILE  ‘outOp; 


») 

bold_on  *{»" 

bold_off  ’(N” 

und  on  *(%’ 

und'off  ’tS’ 

sup“on  *()* 

sup~of f  *  i  ( * 

sub~on  *(♦* 

sub'off 
aux  on 

aux~off  *(*■ 

dx_tllde  ’lx* 

dx2l_brace  "Ij* 

dx~r~brace  *!•* 

dx^bar  *|<* 

lin_aod  *ic* 

com  on  *111* 

dx  tab  *11* 
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» 


* 


0 


dx  nl 

dx“fl 

coi_of I 

space 

hyphen 

wv  hyphen 

ww~ecl 

page  Bark 

treating  hyphen 

pa  r  ag  r apK_Ba i k 

center 

t  ul e i_nodi f led 
tde_on 
tde~c! ; 
tde~cha: 


*|J* 

'IL’ 

•IK* 
•  • 


(aux_on) (und_on} (dx_nl ) 
(aux^on) jdx_nl ) jaux~of f ) 
(dux~on j  jdx~ff j (aux^of f ) 
{aux~on) (hyphen) {aux_of 1  ] 
i aup_on j idx_nl ) ( aup_of f ) 

(tut  onjjdx  nlj(Bub~off| 
(bol3_on j ( lTn_Bod ) (Eold_of  f  ) 
( eoir._on)  (  apace )  ”#5*  (  ceB~of  f  ) 
(coB^on) ( apace  j ”$5" ( co»~cf  f  j 
(coa'on) (apace) 4. (cob_oI£ ) 


any  char 

( I 'Tl 1 1 ldx_tab) I {dx_bar) I (dx  1  brace) I )dx_r_bracc) | )dx_tildc) ) 

white  apace  ~  ({tpaceTlTdx  tab))  ~  “ 

anuiti  “  (  (0-9)4(’.'(3-9).)*) 

dnux  ( (0-9)»*-’(0-9)*) 

nuBoer  ( ( 0-9 )* ) 

f  oricat 


(  ( und_cr. )  i  i  und_c£ i  )  |  ( bcld_on)  1  (bold_of  £  )  |  ( co»_on)  |  ( coir.___o££  )  ) 
tatar?  BODY  ~  _  -  -  - 

tatart  CHAPNun 


Utart  P.EADNL 


kttart  riONun 
kstart  fJCTlTLE 
katart  FIGEND 
ktterl  SECTI7LE 
VV 
M 

BEGIN  BODY; 

H 

<BOOY> ( und_on ) 7 ’SECTI ON* ( apace ) • (nunber ) (und_e££ ) 7/ ( center )  ( 

/•  a  aectlon  header  •/  "" 

Er.lT(  ’<aectnuB>’  ) ; 

ECHO; 

EKITI "</aectnuB>* ) ; 

BEGIN  SECTlTLEj 

1 

<SECT1T1.E> ( (any_ehar )« ( center ) )*/(dx_nl ) (dx_nl )  ( 

/•  section  naae  •/  ~  ~ 

EniT( "<aectitle>*)  ; 

ECHO; 

EHIT{ •</aeetitle>*) ; 

BEGIN  BEAONI.; 

) 

<BODy> (anus) (apace) •/(und  on)7(any  char)«(und  e££)7(dx  nl){dx  nl 
)  (  ■  ■  -  -  - 
/*  a  nuBbered  paragraph  •/ 

EKIT( *<chapnuB>  * ) ; 

ECHO; 

EHIT( ■</chapnuB>* ) ; 
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BEGIN  CHAPNUH; 

) 

<CHAPNU«> {und_on) 7 { •ny_chat ) ♦ ( wj«d_o££ ) 7/( dx_nl ) (d*_nl )  1 
/•  paragraph  na»a  */ 

EniT( '<ehptitl«>“ ) ; 

ECHO; 

EHITt  *</chptitlt>’  )  i 
BEGIN  READNI.; 

) 

<B0DV>((any  char)|(trw  aol  J  |  { £ormat )  )*/(dx  tiin^hita  spact]*(dx  n 

n  {  ■  ~  "  ■ 

/•  a  paragraph  •/ 

Ek:T( “<paraO>"  )  ; 

ECHO: 

E«IT( *</paraO>"  ) ; 

BEGIN  BEADKl.; 

) 

<BEA0N1.>  (dx_nl  I  (wh:te_apacej*(dx  irl)  ( 

/•  eat  new~linea  after  paragrapKs  aitd  hcadert  */ 

EBIT( "\n’ ) ; 

BEGIN  BODY; 

) 

<B0Dy>  (  ( ( any_char ) | (format) )*(dx_nl ) )*(dx_nl )  ( 

/•  a  figureT  maybe  •/  -- 

ERIK  *<£ igbody>’  )  ; 

ECHO; 

ERIK -t/figbody)"  )  ; 

) 

<B00y>*rieure‘' (white  tpace)«/(dtruiii)  (white  apace)»(any  char)'»(cen 
ter)  (  ■  ~  ■ 

/•  figure  title  •/ 

EHIT( "<f igref >’  )  ; 

ECHO; 

ERlK*</figre£>'); 

BEGIN  riCNUH; 

) 

<riCNUR> (dnum) (white_apace)e  ( 

/•  figure  number  •/” 

ERIT( '<£ ignua>* ) ; 

ECHO; 

EHIT(*</fignum>’); 

BEGIN  riCTITLE; 

> 

<riCTITLE> (any_char)*  ( 

/•  figure  name  •/ 

EHIT( *<figtitla>’  )  ; 

ECHO; 

ERIK •</figtltle>* ) ; 

BEGIN  riCEND; 

) 

<PICEND>(eanter)( (whlte_>ptce)*(da_nl) )*  ( 

/*  figure  cleanup  •/  ~  ~ 

BHlT(*\n*)» 

BEGIN  BODY; 


X 
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